 Hello everybody and welcome to this open group webinar on the open group service integration maturity model, the OSIM. I'm Chris Harding. I'm the forum director for SOA in the open group and it is my pleasure to welcome you to the webinar. This will not be a straightforward tutorial on the OSIM. We've already run one of those and the recording is available if you want to understand the OSIM at that level. The intention of this webinar is to answer people's questions on how the OSIM works in practice and we are fortunate in having to assist us with this. András Chacal, who is an expert on the OSIM, is a distinguished engineer with IBM and he was heavily involved in the initial development of the OSIM and has been further involved in maturity assessments. And we also have Dan Stakowicz of Raytheon and he will be coming to this with the perspective of a user of the OSIM and he has some questions that he will be asking András that András will be answering. But the questions we hope will not just come from Dan. Everyone is invited to put their questions to András in this webinar, everyone who is online and if you wish to do so, the way to do it is by using the Q&A facility and to address your question to all so that all the participants in the webinar can see what the questions are. So this will be an excellent way of getting into the OSIM in depth. To start it off though, András is going to give us a brief ten minute overview of what the OSIM is and once he has done that we will get into Q&A mode. So without further ado, I will now hand over to András to tell us what is the OSIM. Hi, thanks, Chris. And thank you for joining us. I'm looking forward to Dan's participation and everybody's further interest in helping the industry adopt the OSIM model just to remind you OSIM stands for the Open Service Integration Maturity Model. So the first thing we should say is that this is not quite like any other maturity model. It is a maturity model per se, but it is extensible and we'll go through that in a second. Also too, it's not about SOA per se. It's about service integration and we intentionally tried to stay away from the word SOA because we believe that SOA was obviously going to change in its maturation and point of view and we didn't want to be tied necessarily directly to a particular point of view on technology. Likewise, we didn't call it cloud either but you could really interchangeably use the word cloud in SOA in most cases. It is a service integration maturity model so it's how well you've adopted a point of view according to the OSIM framework and where you're going potentially and provide you with a path for getting there. It's an extensible maturity framework that is that you can fill it up with your own contributions and we'll see how that kind of works as we move forward and it's a process for maturity assessments that helps you define the overarching process. Let me go on here. The other elements that OSIM focuses on is understanding how the business and the IT domain play together to achieve a business objective. We define our current state and we're reaching for a future state that actually tracks very well with both of our IT and business strategies. How do we realize those two in tandem or how can one support the other? Obviously, IT must support business. That's done so using the dimensions across the OSIM model, the applications method, the information model, the operations, the architecture and influenced by the governance and organization. OSIM doesn't suggest a big bang approach. OSIM is all about evolutionary approach to reaching your future desired state. Obviously, your enterprise architecture and your incremental approaches are very important in using OSIM. OSIM is not something you use once and just put it down. OSIM is something that is useful in stages to assess where you are today with respect to the maturity matrix and how far you've gotten and the progress that you've achieved. Here is the ubiquitous OSIM maturity matrix. This is the 7x7 model that shows the maturity levels and the domains. The domains are on the vertical and across the horizontal. We have the business view, the organization and governance, the methods, the applications, the architecture and the information domain and the infrastructure and management domain. Intersecting those are the maturity levels. We call these level 1 through 7, but we also gave them a name. Don't get too married to the name. We try to make them as generic and descriptive as possible. For example, you could pretty much see cloud computing begin to evolve in the later stages of the maturity model. That was certainly something we did intentionally and so much as that we were beginning to see the advent of cloud when we started working SOA. Cloud computing is an important element of everybody's lexicon today. You really have to think of it in terms of service integration because you need a service platform. You need to be able to actually connect to your existing systems and create service components. You have to externalize services. You have to implement composite services. You have to be able to virtualize those. Then ultimately the OSIM matrix talks about the dynamically reconfigurable services, that is those services whose composition are not strictly tied to a static point in time, but actually are dynamically responding to business changes or technical changes for that matter. We also have this concept in the maturity matrix of the service foundation levels. These are the baseline technical requirements for achieving services. A lot of folks have said why didn't you just remove those? Fact of the matter is that even with existing SOA projects in place existing systems have to be extended. Value has to be extracted. We're seeing a lot of acquisitions and mergers still. Consolidation across business objectives. Really those take almost a very green field integration approach to extracting the business value. You still have to go through this or you still have the situation where you have siloed systems or siloed data that needs to be integrated and extended componentized and ultimately used in services. We think it's still very important to have the service foundation layers called out because you need to realize that there's this constant evolutionary approach to extracting the business value through services out of your infrastructure and business processes. Just to kind of call out the domain, a domain example here we have for example in this particular chart, let's say level five, if we go back up here to the maturity matrix we see that level five is composite services and we have a set of fundamental attributes in order to actually be considered a level five maturity and we have a set of evolving attributes. What we are trying to do is make sure that the OSIM tracks with our future published SORA and so we've done some tweaking there over the lifespan of OSIM to make sure that it tracks very well with what we're about to publish with respect to the SORA and we're going to make some updates to the SORA as we go forward OSIM to make sure that it tracks with the naming conventions defined in the SORA as we go forward like the use of architectural building blocks. If you look at the SORA model which we've published some of this already just to let everybody know where we are and we intend to publish the entire SORA this year, the business processes are really and business process optimization and business process management shows up as we move from level six, I'm sorry level five to level six and this is an example of where we can actually integrate the SORA into our lexicon for OSIM. But in this case we have a set of fundamental attributes like for example the need to have a services registry and repository, business processes are becoming composite, ESB is common, we're doing transformation and integration and service advertising through the ESB, use of B-Pill and BPM to define business services and common security services and the policy model behind them are an integral baseline requirement. Evolving attributes may be the master data model and a master data model MDM service and operational virtualization service which is evolving. We have continued maturity in the SORA process monitoring and management capabilities so that we can provide insight into both our business processes, the activities that are actually being conducted in the business process itself as well as the technical aspects and then we have an evolving integrated identity management and security policy management model. So at this time, now that I've done that fly by, I'd like to hand it over to Dan and we can start the process of asking questions and really getting down into nitty gritties. Thanks, Andres. Great overview and welcome to everyone online. Point out that Andres, we're already starting to get questions from the attendees so I'll weave my own questions into the ones we're getting from the attendees if that's okay. So one question I had, Andres, with regard to applying the model, the OSIM model, have you identified or observed anything, any best, what you would consider to be best practices in putting the model to use? Oh, absolutely. All right. So let's not forget, and I'm going to come on down here to the assessment mind map which you can actually get a copy of this presentation. Most of this presentation is online from our webinar that we've already done on OSIM. And just like you have the old saying or the old adage with respect to buying real estate, it's all location, location, location. Well, with OSIM, it's all about preparation, preparation, preparation. So obviously you've got to spend some time understanding the model but you really need that prep time to load the model so that you have the right maturity indicators and the framework set up that is aligned to your EA and SOA strategy so that when you go in and you prompt, you go through the process of interviewing or data discovery that you find the right information that it leads you to the correct assumptions with respect to the maturity levels that you're marking on. And OSIM is really a great way to actually make sure that everybody understands your corporate strategy with respect to the service integration and services models. And so this is a way that you can actually get the perspective of individuals from the infrastructure guys all the way up through the business analysts who understand where their vision is, but it may not track necessarily with a strategy and may impact really where you are from a maturity point of view. So I'd say preparation is extremely important. Any other best practices that you've observed? Particularly if we have one question from the floor, Andres, which is interesting, is with regard to say convincing senior levels of management that the OSIM is a good tool to help construct a roadmap. Well, look, I love SOA. I'm a techie as much as any of the individuals in this webinar. I'm also an executive and a VP. And when you get to that level, they don't really care about what tools you're using. They want to know what the outcomes are, what the indicators are. So telling somebody that you're going to use OSIM is great. Really explaining the value that it's going to bring is more important. So what you're trying to do is to be inclusive, and you're trying to make sure that you evolve so that you realize the business value and the return on the investment the company or organization is putting into implementing a service infrastructure and a service model. So that I think is the approach I would take when talking to executives versus talking to technical folks who probably want to know a little bit more about the nuts and bolts about how this is going to work. Now also too, your presentation is going to be really important. So if they say fine, I don't care whatever tool you use. How you present the results is going to be equally as important as using the model. And if you make it too busy or if you suggest that now there are too many problems, that could be an issue all in of itself. So some of this is about executive presentation. Some of this is actually about doing the right work with respect to crafting the results. And the other part is actually pitching the value of OSIM. Great. Thanks, Andres. Another question was with regard to whether or not the OSIM model has drawn from or leveraged the SCI maturity model or the CMMI maturity models that are there. Is there a relationship there? Has this leveraged some of that work? So we've had this question in the past and let me kind of preface it by saying that in my previous company one of my responsibilities was to actually help the company evolve to CMM level three and heading towards four and understanding the SCI maturity models and kind of culturally approaching transformation using those models as tools. All these models are tools. It's really in how you actually apply the tools and whether you're focused more on the tool than you are on the practice which is not a best practice certainly, something that you should avoid. So my feeling is that I've seen a couple of customers use the capability maturity model in conjunction with OSIM to arrive at a repeatable process for implementing service integration across their portfolio. So I really see that, for example, CMM or CMMI might be a kind of broader perspective on end-to-end IT process integration than OSIM which is very, very focused on achieving certain specific goals around service integration. So you certainly could use both at the same time. And let me just build on that a little bit. Have you had some observations or experiences that you could share with us with regard to using the OSIM in conjunction with some structured architecture models such as Togaf, for example, or Dodaf or Zachman approaches? Okay, that's a great idea. Let me run through here and try to find the chart that I'm looking for. Oh, there it is. So look, Togaf and Zachman are tools, again, just like any tool. Zachman focuses on EA model perspectives and EA taxonomy whereas Togaf takes a more evolutionary lifecycle approach and service taxonomy approach. So I would say that from a Zachman point of view, OSIM would help you load the different model perspectives as an evolutionary outcome of the assessment and that I think Zachman and Togaf both talk about an evolutionary approach. So again, OSIM is not about doing the assessment once and then putting it aside. It's about doing the assessment, probably, let's say, quarterly and helping load the current as-is models into both our Togaf and our Zachman perspective. But with respect to Togaf, I think of it as kind of integrated into the ADM and so you may actually do an OSIM assessment and its outcomes are then used in the different crop circles. For example, as part of architecture vision, as part of business architecture, you know, the business process perspectives, the results and the data that you harvest there would influence your Togaf's decisions. And of course the IT and infrastructure pieces would influence phase C and ultimately then you would move into implementation. And once you got back around to the top and you were doing another rev, maybe it's not another opportunity for you to conduct another OSIM assessment. Great. So one of the features, I think, of the OSIM model is that it not only provides you with starting points, but also a framework and some encouragement to customize the model for your particular industry or use. I was wondering whether or not you had some experience with customizing the OSIM model for a particular industry and any recommendations on how to go about carrying out customization and defining maturity criteria with the customized maturity indicators. Right. So customization of OSIM is extremely important, both from creating the proper indicators and the attributes that you're looking for, but also to the assessment questions that would lead you to harvest the right data so that you can make a decision about the measurements that you're going to make. So in other words, the specific measurement that you make is really the data leads you to define maturity level according to the maturity indicators defined by the maturity attributes or the characteristics. So in the last webinar, we actually went through the case study for DDB and the fact that they had adopted Mimosa and were using the Mimosa and the OSA EAI architecture as a foundation, kind of enterprise architecture perspective for solving some of their problems. And we really went through the process of creating new maturity indicators, attributes, and the assessment. So go and actually dive into that webinar. And I'm sure Heather, myself, and Dan and others, Chris can help facilitate questions back to the group if you have any about actually conducting those. That process of creating the indicators and assessments, because I think really it's really important to sit back and look at what your enterprise architecture is, what your strategic objectives are, both from a technical and business point of view, and craft well-formed maturity indicators. And if you look at what we've done in IBM with the SOA assessment tool, we actually have a tool, and we're not the only company that has one, by the way, that gathers all this information and allows you to actually modify the framework and automate the process of conducting the assessment. So you might want to either create your own tool or get involved with a company that has a tool, because I think these are all very important kind of supporting capabilities that allow you to actually conduct the right OSIM assessment. Safe to say, though, Andres, that in developing customizations, along with maturity indicators, that the approach starts with understanding the strategic objectives of the organization and then decomposing those into the technical architecture. Would that be fair? Absolutely. I mean, you certainly can have a technical approach to implementing the SOA infrastructure that can be a separate initiative from your business objectives. Because there's some foundational requirements that have to be operationalized in order to actually instantiate the business processes. But the two have to come together and the two must support each other. And you don't invest in IT without understanding the return on investment, right? So there are quite a few, and if we go over here to the SOA RA, SOA services are what we call architectural building blocks that pertain to each one of the layers in the RA and ultimately to correspond to the maturity levels. And you're not going to need all of these. It really depends on the business requirements, the services that need to be externalized, and the quality of services and policies that have to be implemented and put in place. So your business must drive certainly your IT investment. There are some basics, though, right? That said, having a service registry repository is very important. Having that application server integrated with that SOA registry and repository is important. Having this security in place to be able to manage policies is a foundational requirement. So there are some base requirements out there that are necessary to actually realize SOA that you could be putting in place in advance of the business, but ultimately you're not going to make that investment unless you know the return on value. As an aside, I'll point out that we have had some questions about whether we have a list of maturity indicators and waiting for those during evaluation. And for those on the call who have that question, I would refer you to the OSIM specification, which is available from the Open Group website. And in the specification has a list of initial maturity indicators for each of these levels and weights that are associated with them. Again, I'd point out, as Andres has shown here, that these are available in the technical standard and they're positioned as a starting point. There's lots of encouragement in the standard for you to customize the OSIM model for your particular use. Andres, I had a couple of questions here. One of my own and one from the seminar here about the scope that we're concerned with when applying the OSIM model. As we discussed before and my experience on the one hand, you can certainly apply the OSIM model to your own enterprise to assess where you are in a maturity process, a maturity level with regard to realizing systems integration. On the other hand, you can also, it seems, apply the model to a target customer organization to help them assess their readiness, for example, to accept a software or system delivery that integrates their systems. So have you seen the model used in those two types of applications and any observations or comments about using it in those two ways? Yeah, I mean, we have done actually hundreds of OSIM assessments. And the two areas which they impact the most is in making strategic business decisions and then determining the readiness of the team that will be doing the implementation of the SOA infrastructure. So it's really impactful from a point of view of being able to help you kind of understand what are the kind of moving pieces and parts and do you have the right skills and infrastructure necessary to basically realize your enterprise architecture, strategy and vision. And the other one obviously is helping projects understand the needed investment, where are they today, where do they believe they are going, and what are the steps that they have to take, the evolutionary steps that they need to take in order to get there. So I think we talked about this before, you and I, and you really kind of brought up a point that I hadn't thought a lot about, but being able to kind of assess yourself or assess a group of individuals on their ability to be able to actually implement services, cloud computing, flash SOA, and their technical skills I think is a really excellent way to utilize the model. You probably would need to update the maturity indicators and the attributes to help align with some of those activities, but then that's what it's here for. That's right. So let me build on that a little bit, Andres, with regard to scope. How would you extend the OSIM model to, I think what we'd call in Togaf, an extended enterprise architecture, or an architecture that is federated across partners and suppliers that each have their own, say enterprise architecture, how would you use the OSIM in an environment like that? Well, I think in that case you really have to think in terms of service interoperability as well as integration. So your architectural objectives have to be reflected in the setup for an OSIM assessment if it's going to be useful. So how are the partners going to integrate their business services across a value chain is going to be something that you're going to have to have a handle on. And in that case it's going to have to be focused on understanding the business processes and the business outcomes and ensuring that you're able to actually measure those processes so you understand what is success and what is not of value. And it's going to be less maybe based on soil infrastructure. So you may have to change some of the indicators to be able to support that. That's a really interesting idea of using it to actually help a business ecosystem, a value chain understand whether or not they're effectively approaching service integration correctly. So I think it would be obviously you would have to define an overarching strategy for each of the partners to follow with respect to service externalization and then you would have to establish a set of maturity indicators and attributes and the proper waiting for them to be able to assess their maturity against those objectives. So thanks, Andres. We also have a series, I'd say two or three questions that I'm going to group together that address what I would characterize as some of the cultural issues regarding moving an organization from wherever they're at to a more mature, service integrated organization. And I was wondering if you could comment from your experience on using the OSIM as a tool to not only guide and direct, but encourage the cultural transformations that are required in an organization? Yeah. I would agree 100% and I'm going to go back over here to the tutorial and the tooling example here. And let me go ahead and pop up here to the process. Yeah. So in my mind OSIM in a customer engagement atmosphere where I'm either internally consulting across development teams or with the customers trying to understand, all right, so I have a need to implement services. I want to create a service environment for you and Raytheon that would be potentially a mission oriented service environment which has a certain set of quality attributes, quality service attributes that are necessary to meet as well as business processes, for example. And it's very much an assessment of that organization's ability to understand their own strategy. So there's the framework set up which you have to work with the customer on or the target organization to actually create, you know, to populate the framework with the right maturity indicators and attributes just from the start. And in doing that, I found that you can glean a significant amount of information across the organization about different perspectives, you know, and competing perspectives. And it brings people together. I mean, I've had, you know, a tremendous number of examples where we have customers come in and you get different perspectives from different business leaders. And the IT department versus the business analyst, you get them put in the room and nobody has ever done that before. And they're put in the same room and they're asked, you know, to help answer some of these questions that we come up with in the SOA assessment and agree on together as a team their maturity levels and how you might actually go about meeting the requirements to evolve to their envisioned goals. And it's just a fantastic, you know, magic that occurs when you finally force people together and create a shared vision. So getting everyone into the same framework, talking about the same issues. Using the same lexicon, yeah, is really important. Significant step forward, absolutely. A couple of questions with regard to other, say, emerging maturity models. I know that in the energy management community, for example, several efforts to develop a smart grid maturity model. Someone's pointed out also, Stephen Amsbury pointed out there's also healthcare maturity models that are emerging and also leveraging SEI. Have you had a chance to look at those or been exposed to those? And is there, do you see overlap between OSIM and these other, particularly in the smart grid and healthcare areas, these maturity models there? Yeah, I see some overlap. I mean, but they're trying to evolve or define your maturity with respect to already a predefined set of industry strategies, right? So if your industry has basically been, let's say, required by policy or law to go in a particular direction, some of these industry models are quite useful. In general, most of these maturity models, with the exception of CMM and SEI and so on and so forth, the OSIMs of the world, they're really in disguise trying to help you achieve the implementation of an industry framework. And that industry framework is either managed by a consortia or a set of companies who have a goal in mind. And obviously the goal is to achieve industry adoption of their perspectives and technologies. So OSIM is a little broader. You can use all of these in the context of OSIM. OSIM might be your conscience that helps you understand that not every requirement, policy, enterprise architecture, directive is necessarily going to lead you down to a more mature service slash cloud slash SOA environment. They may actually require you to become more stovepiped in some cases. And you may realize that through the adoption of OSIM as a practice culturally. So would it be, how would I say it, safe or a reasonable approach, I think, to use the industry-specific maturity models as a source of information to, say, expand and specialize the OSIM for a particular industry? Yeah, I mean, look, all of these models are tools. And tools are only successful when you have somebody who actually understands how to effectively apply them, right? And any tool can be misused. So the industry models are intended to help industry partners integrate and rally around a set of perspectives and requirements. And the OSIM is really more about being able to measure your adoption of service integration across your infrastructure and forcing some of this group decision-making around how you might actually achieve some of your objectives. So, in a way, it has some attributes that are very similar to EA. But if you say EA to people, they sometimes get all choked up, right? And by actually conducting an OSIM assessment, you may actually, you may be able to glean data that can help populate your enterprise architecture model. Andres, I had, we had discussed briefly, and I haven't sent it to you yet, but promised I would, that there was a U.S. government, U.S. Air Force had issued a request for information. And in that request for information, they used the OSIM maturity model and referenced it and asked the respondents to assess themselves against that, against the OSIM. Do you know where else the OSIM is being adopted by procurement agencies or industries? Well, I have quite a few customers that have used it. And unfortunately, just like EA frameworks, they don't really want anybody else to know that they're using it. So let's just say that we've had thousands of folks download and use our tools or engage the services team on them. And so I see a broad adoption of OSIM. I see the public sector adopting OSIM and using it in assessments across the military space and the civilian space. And it's funny because sometimes they come to IBM or they come to a Capgemini or others that have the tooling. They use it for the first time. They hire the consultant, and then they culturally adopt it internally and then come up there with their own tools, their own perspectives, and it begins to have a life of their own. And, you know, you certainly, you know, obviously, I don't want to suggest that you lose the ability to have traction with a customer after that as a consultant. But, you know, you much rather have the customer adopt, you know, OSIM broadly and culturally and make it part of their DNA than to constantly be trying to explain to them that, you know, well, the reason why this project failed was because you didn't do the due diligence that led up to making some of the decisions about how you were going to externalize some of your services or implement the infrastructure or, you know, how you were going to segment your business processes. Yes. So with the wide use of OSIM and the feedback that you're gathering as well as other practitioners, where do you see OSIM going in the future? Well, like I said, we're very much looking forward to Ali Asanjani and the other folks on the SORA team finishing up the SORA. I want to take another pass at the OSIM specification and make sure that it's up to date with the respective terminology used in the SORA. I want to come up with logical models that track with the ABB definitions. I want to, one of the things that I always wanted to do with OSIM was to create a repository which you, the technical experts, could provide input into as examples of using OSIM and create new maturity indicators and contribute them, like as open source. We've been doing so many of these webinars and outreach engagements and even personal engagements with companies to explain to them the value of OSIM. It's been a little exhausting over the last few years, but I think we've gotten to the point where now we've got a group of companies have adopted OSIM and they're willing to probably help with some of these new maturity indicators and externalize them as open source. That's really where I would like to see OSIM go. Here are some of the maturity indicators and the attributes, and this is the assessment roadmap that I used and this is the value that I got from it. You can actually take it up and let it level and not basically disclose all of your corporate strategy, I think. This would probably be very true with respect to the public sector where most of the work is done in the open anyway. Those are the areas that I'm looking to help push the adoption of OSIM and mature OSIM in general. I'm really very much looking forward to the adoption of the SOARA and creating logical representations at each maturity level. Could you, in your slides there, go back to the maturity grid? Sure. A few questions with regard to the position of cloud computing in here. Obviously, the model is, well, not dependent on SOA, cognizant of SOA. How would you see cloud working itself into here? Now you've got me passionate, I think, because I have to say that I'm not a huge fan of saying the word cloud. You can say cloud, but what does it mean? It's like saying the history of computing. My feeling is I'm going to take a different perspective on your first point about cloud not being SOA. Cloud is certainly, at its core, service-oriented. OSIM is about service integration, so it's the ability to actually realize services and business process management and the instantiation of your business processes into those services and the ability to ultimately dynamically configure as changing business dynamics occur, those business processes. And that's really, if you were to think about this in terms of its core elements, you would probably find the definition of cloud in there. So virtualization, service integration, the focus on master data management, infrastructure virtualization, as well as governance. All of these things are all part of cloud computing or part of some instantiated implementation of service model, which you are calling cloud. I know a lot of companies that took a look at their portfolio and said, well, we'll just rename it. And they were already doing, to a great degree, service-oriented computing. I think the big difference between cloud computing and basic SOA is this idea of being able to commoditize a particular service and have a grid computing approach that allows you to kind of pay by the SIP via utility computing model of some sort. That doesn't make sense in all cases. In fact, I would say in most business processes, it doesn't make sense. And I think that we're coming to a conclusion that, hey, there is some realistic approaches to cloud computing that service orientation has taught us along the way that we just simply forgot in the hype. So I absolutely think that the OSIM model is 100% viable today with respect to any cloud approach. Now, if somebody thinks otherwise, then I'm willing to have that discussion. But I don't know of too many cloud infrastructures that are, quote, dynamically reconfigurable from a business process point of view yet. You have some models that are trending that away. But in general, I think that we're absolutely on target with respect to level seven in the OSIM. Now, later on, we might have to add a maturity level that tracks with a slightly different perspective as we grow service integration and cloud computing and service oriented architectures. I think we're closing in and we have about nine minutes left, I think, in our scheduled time, Andres. I think I've tried to pose some interesting questions for you as well as summarize some questions we were getting from the attendees. Any other things that you think would be relevant to bring up that we haven't covered? Hmm, relevant things that we haven't. Well, let's go through the questions, I think. Here, is there anything that we missed? There's a question about, I just came down to the bottom of my list here about, in the process of going through an assessment, you're going to be identifying relationships between different elements within the assessment model. And have we looked at using, say, semantic model? Yeah, right. We have a semantic model for SOA that Chris can certainly hype up here. And the SOA reference architecture actually does exactly that. It shows interrelationships between architectural building blocks at each of the layers of the SOA RA. So that's one of the things that I do think that the SOA RA will be a fantastic boon for us with respect to OSIM because you'll be able to actually kind of make some inferences about ADDs that are necessary at certain maturity levels for you to achieve your desired business outcomes and the logical architecture that you'll need to be able to support. And ultimately, you know, that'll help you inform your physical implementation. So, you know, what infrastructure you need, what products you need, what platform do you need. I really believe that, you know, this discussion of cloud computing is really more of a platform discussion. You know, and that's our perspective certainly within IBM and that is that we're seeing SOA become a new operating platform. And, you know, this whole trend towards, you know, or the previous past trend of trying to select and integrate, you know, different components of a service operations environment and trying to build those up into an operational capability that lets you offer services is probably going to die on the vine here soon as companies begin to offer service platforms instead of, you know, individual products. So, you know, you'll be able to buy a service platform from IBM, a service platform from other companies. And we won't be in the, we won't necessarily have to worry about, you know, finding the right service registry and repository or finding the right, you know, security product to manage Web Service Security Force because it'll all be built in together and we'll really be talking more about what components do we turn on and what are necessary to offer a particular service. Right. Seems to be the direction we're heading in the industry. Sorry, just to break in there and clarify specifically, what Andras was referring to when he started, there was the open group SOA ontology, which is a formal ontology for SOA, expressed in our, though we've also tried to add explanations and examples in English and indeed in UML. So yes, there is a formal ontology there, which we believe the RA and the OSM are consistent with. Yeah, and there's work going on in other consortia and relationships with other companies that, you know, across the industry, you know, with IBM and other companies to actually implement models that track to these, to SOA and to the ontology work that we've done. Okay. So we have five minutes left, Andras. We want to scan through the Q&A panel there and let's see what I missed. Well, there's another one just come in. Did we talk about the use of the OSM? There was a question earlier about delivering value at the earlier levels, maturity levels, as well as the later ones. Right. And the fact that the OSM covers a broad spectrum of maturity, we maybe tend to see dynamic reconfiguration as the most technically interesting thing, but perhaps there's value at the early maturity levels also that we could talk about. Yeah, well, I got to tell you what, the most, you know, value that a corporation realizes when implementing service integration across their portfolio is between level three and level five. Why is that? Because of the lifespan of a business process, you know, isn't tens of years or isn't even, you know, maybe three or four years anymore. It could be as little as months. And so there's really no, you know, value or return on investment to making some business processes highly mature services because they have a very short span of value. That said, there are probably some infrastructure capabilities that would allow you to do things like dynamically provide feedback as to, you know, what products individuals are ordering and repopulate your inventory and so on and so forth that certainly would qualify as a dynamically reconfigurable service. But you're probably only going to have a few level seven services and a whole lot of level four, five, and six. Okay. So yes, we'll be talking about three to five as being where they're being the most value is, but there's still probably value even at level one. Oh, yeah. Like we said, Chris, you know, most of the, you know, organizations these days are, you know, you're consolidating organizationally. You know, M&A is still a significant business focus. I mean, look at T-Mobile and AT&T, that's going to be a huge M&A, you know, transformation effort that's going to have to happen there. Many other companies, you know, including, you know, my own, going through that process. And you really have to look at these IT systems from a data perspective. And as you do, they're going to, you're going to have to establish a service foundation layer. And that's going to mean you're going to have to, you know, take the silo, you know, break apart the components, integrate, you know, make them integrated and externalize them as services to be able to utilize them. Or you, you know, basically deprecate some of them in lieu of some other services, right? But regardless, you have to look at that as service foundation levels. Okay. So I think as we're drawing towards the end of the hour, that's possibly a very good note to end on. OSIM is all about assessing maturity, and it's a complete graduated scale that enables you to assess your service integration maturity from, if you like, the beginnings of thoughts about SOA right through to a very technically advanced and well-developed solution. So the OSIM, I believe, is of potentially great value, and it's been great that Andras and Dan have been here to help people gain some of that value by asking questions. And I'd like to thank Andras very much for the depth and extent of the answers that he's given to those questions. And I'd also like to thank Dan very much, first of all, for sharing with us his questions as to how the OSIM should be deployed and what it's all about. And also for doing such a great job of looking at the questions that have come in from people on the Web and putting them to Andras. So Andras and Dan, thanks very much indeed for your participation in this webinar. And thanks indeed to everyone who has attended the webinar and has asked questions or indeed has simply participated and gained value from it. Thanks, everybody. Thank you.