 OSEM is the Open Service Integration Maturity Model. It's an open group standard that's available in both PDF form from the open group bookstore and an HTML form from the open group's solo page. Our presenter today will be Andras Sazako. Andras is an IBM Distinguished Engineer and Chief Architect of IBM's Federal Software Business Unit. Andras is also an open group distinguished certified IT architect, an IBM-certified solo solution designer and a certified secure software lifecycle professional. His responsibilities at IBM include developing e-government software architectures using the IBM Middleware and leading the IBM US Federal Software IT architect team. Andras has been the driving force behind IBM's adoption of the federal government IT standards and is a member of the IBM Software Group Government Strategy Standards team. This team has been responsible for helping the federal government move the government into an on-demand era through the application of SOA and cloud computing. He's also a member of the Security Architecture Board and Secure Development and Cyber Security. So not only is Andras an expert with SLA, he's also an expert in security. Andras represents IBM on the board of directors of the open group and currently holds the chair of the IT architect profession certification standard within the open group. Andras did lead the OSIM standardization work group and resulted in the OSIM standard in August of 2008. And he's currently working with Heather Krieger, myself and others to have OSIM approved as an ISO standard. Well, Heather, thank you very much for that incredible introduction. This is Andras the call again and we're here today to talk about the OSIM standard, which stands for the open group SOA maturity model standard. It is actually not your traditional standard as in APIs. This is a technique and we're going to kind of walk you through the value as a practitioner of using and applying that technique. Actually multiple tutorials, some of which are already online for your use, we are going to actually be talking about the OSIM, but in the past we've done the impact of SOA on business. I think Heather is one of the folks that contributed to that. SOA governance, architecting SOA and developing a SOA using Togeth, the open group architecture framework, and then implementing SOA. So if you're interested in those, by all means download them and use them. Today we're going to essentially focus on four major areas. We're going to do an overview of OSIM. We're going to use our DDB or Dursley drill bit company use case and case study to review how we might as practitioners apply OSIM. We'll use industry standards as a method to foment discussion and come up with some conclusions and hopefully take some of your questions. So what is OSIM? OSIM has three different major facets or elements to it. It's a service integration maturity model. It helps us understand how we can more effectively integrate SOA services, and we are all talking about cloud computing these days, so cloud computing as well, in a fashion that helps transform our business. It's also an extensible maturity framework. So it's not static. It's meant to actually be modified and used in the context of the organization looking to transform. And it also, in that context, provides a process for the maturity assessment. So OSIM helps define a roadmap for transforming your business. It defines an incremental approach to taking SOA or services and adopting those SOA services or cloud computing services in the context of a business transformation. So we don't simply take technology and apply it willy nilly. We always do this as effective architects and practitioners in the context of the business problem, in the context of business transformation. So it allows us to understand how we would approach the implementation of both business process and technology as it exists today and how it must be implemented in order to achieve our goals or strategy. And it does this in the context of multiple dimensions. So the application dimension that we're all very familiar with, how we actually are going to approach the implementation of these services, whether they be true SOA internal services or cloud services, what are the governance mechanisms, what are the methods that we might apply, how do we manage information in this context? What are the implications to operations? All of these different dimensions have to be considered as we move from our current state to a future state of both IT implementation and operations as well as the business processes that sit on top of our IT infrastructure. And our strategy, our goals, our priorities and imperatives help inform this transformation process. So when I say priorities, I'm talking about business priorities and strategy. When I'm talking about imperatives, I'm really talking about those requirements to implement applications in a certain way that your organization or government or entity that's using this might have defined as part of their enterprise architecture. So this is the OSIM maturity matrix. So at the top of the OSIM model, we have the maturity matrix. And it's a 7 by 7 matrix which defines maturity levels and the dimensions. So we're interested in these different dimensions, as I mentioned before, that are important as we transform our business and technology infrastructure to adopt the, as we go through the maturity process, to adopt the different technologies and business approaches that are necessary for us to meet a certain set of objectives. So some of the dimensions are, as you see in the vertical on the left-hand side, are the business view. So what are our business objectives? What are our business processes? How are we governing this transformation process? What is our organization like? How are we organized and how should we be organized in order to actually achieve this transformation? What methods do we utilize? And this is not only about technology methods. This is not just about design methodology. This is about how we actually approach the end-to-end business-to-IT transformation. So there are multiple methods that may be at play here. There are different applications constructed. How do we approach the implementation of the architecture? Information is very important. So the structure of information, the governance of information, how we actually have our master data models established as we move to a distributed service-based infrastructure is going to be very important. And obviously how we manage that, secure that, and operationalize the service infrastructure is also quite important. Now across the horizontal, you see that we have different levels, level one through seven. And we also name these levels. We use the names interchangeably. At level one we have silo. Level two is integrated. Level three is componentized. Four services. Five is composite services. Six is virtualized services. And level seven is, well, it's nirvana, right? Now seriously, it's dynamically reconfigurable services, which is a mouthful for basically the ability to have your services dynamically change as business dynamics change, right? So your infrastructure makes changes as the surrounding business environment changes, which certainly is to some of us maybe nirvana. But it really is the goal of cloud computing and service-based implementations. So if we look at a few other elements of this model, we see that we have this piece that's sort of orange called the service foundation levels. And those are the levels that are necessary to achieve what we call pure SOA services. And we actually did kind of consider leaving that out of the model, but then we would be leaving behind some really important background information and experience and expertise in so much as that we have to transform most of our applications even today, even if they're service-based from the silo point of view. Because if you're doing an M&A, if you acquire a new company, you often find that maybe a line of business created a capability of some sort, they operationalized, and it's really very siloed. It can be siloed with respect to the information it uses and shares. It can be siloed with respect to how many services it can interoperate, the platforms, so on and so forth. So it's really important to realize that siloed applications are not simply going to go away because we move to a service-based infrastructure. And how you actually integrate those is important, and then componentize those, break those down into consumable pieces which we can use as services is also very relevant to the implementation of SOA and cloud computing. So let's take an example here of what we call Level 5 architecture domain of the Level 5 architecture domain and their attributes. And we're also going to use the evolving open group reference architecture to help define this maturity. So there are some fundamental attributes of composite services or Level 5. Now we've already achieved service enablement, right? So we're one level above that on the matrix. And the fundamental attributes of composite services are that we're using some sort of registry and repository to enable the management, the government, the reuse, the visibility of services themselves. And we're basing the implementation of our services on some sort of business process language, right? We can define business process above and beyond simply the service components themselves. We know that we probably are going to do this with some sort of enterprise service bus, and we're going to need an enterprise service bus for integration, transformation, routing, and all sorts of other services that are part of an enterprise service bus. And we're very focused, as I said before, in adopting some sort of business process modeling capability. We have to be able to model our business processes. We have to adopt the standards which define those models, and we need to be able to monitor them in-site to you in real time. We also believe that there are some common security services that you're going to need in order to actually truly be service-based, especially in this day and age when we're all worried about cybersecurity. Now, within each element of the model, we also have evolving attributes. That is, that attributes which you will need to achieve or should be looking to achieve in order to meet the next maturity level. And in this particular case, you know, it's use of master data management. We're working hard at level five to integrate our data in a way that gives us a single view. Do you have to integrate all the repositories to do that? No. You implement a master data management service. There is operational virtualization, which is occurring across the infrastructure. We're also looking to achieve business process monitoring and management. We can actually change our services or at least perceive the necessary changes by effectively monitoring our business processes. And as we go to a service-based or cloud infrastructure, one of the most important elements of operationalizing your implementation is the ability to understand the implications of use as well as debugging. Now, when we have distributed components working, you know, actually dislocated from your current environment, you have a business process that's running in a partner infrastructure and you don't have authority over it and maybe even the visibility you'd like to have, you actually must implement in your environment business process management more effectively so you can understand maybe where exceptions occur. Without that, you will never achieve level six or seven. And of course, we have an evolving need for integrated identity management. Those security services that are necessary to be able to manage identity across an Indian business process, whether they're owned, whether those business processes are directly owned and operated by your organization or not. And in those cases, that's probably even more important. And therefore, you must have some sort of established security policy management in place, too. Now, if you look down at the lower left-hand part of this chart, you see that this is our SOA reference architecture and this is part of the original paper that we published within the Open Group on this particular subject. And we're hoping to actually finish the standardization of the RF soon on the RA. And we're going to use that and to extend OSIM later on. Now, the majority of what you're seeing here at level five is occurring in this business process layer here in the reference architecture. And so you can see in the business process layer that you have composite capabilities. You're beginning to see the development of business processes across the different services. So you're managing the different services as processes themselves. So stay tuned on the reference architecture. I know Heather is looking for that one to close here soon. Let's talk a little bit about case study because we're here to talk about how, as practitioners, we're going to apply OSIM. So if you've done any reviewing of these particular seminars, you know that we have a case study that we use called the DDB Group Case Study, which stands for the Dursley Drillbit Group. Now the Dursley Drillbit Group is a company that manufactures manufacturing components. So drill bits, cutters, all sorts of new widgets or widgets in general necessary for manufacturing. And that is they've even gotten into robotics later on downstream. They were formed, they're a long-lived company. They were formed in 1882. They had success because they basically provided the best quality products. They had a patented product line. They protected those products and those patents effectively. And I would say that probably they became very successful mostly because they had such quality high-end customer service. And they've moved beyond simply Europe to grow globally and they've implemented this growth through acquisitions and some semi-autonomous operational implementations. But things are changing here at DDB. Their competitors are biting at their ankles and they need a united front to the customer. They have to establish this global branding and they've got to look more like one company instead of a bunch of segmented businesses. This reminds you of somebody. They need to reduce their administrative overhead in this environment and they need to preserve specialist production processes and rationalize their post-production processes. So they really want to be able to do on-demand manufacturing. And on-demand manufacturing means that they have to have a view into their business partners' environments and there has to be direct integration with those business partners and customers so that they can actually obtain orders for parts in real-time, manufacture them, provide them as needed instead of holding an inventory, which is evolving quickly and holding any inventory on the shelf is a liability because liable to be out of youth or less valuable as we move into the future as their business partners' products evolve. So they produce high-end drill bits like I said. They're a perverted supplier to major machine manufacturers, so on and so forth. I think I caught you up on all of those assets. So what's most important here is that DDB must participate in a global manufacturing value chain and those partnerships to have the state competitive grow their business and emerging markets and embrace industry standards. Almost underneath their feet, the industry has been collaborating and coming up with new standards so that they can integrate across the value chain effectively. And you've got all sorts of changes that are now putting pressure on DDB sales and revenue. So this is our top-level chart for DDB and this shows that they have their traditional ordering mechanisms. They have order management components. They have a production management capability which is connected to each of their production facilities that are aligned with dispatch management and effectively one-off integrations with online ordering. It's not particularly well-integrated. It's basically you've got a graphic. You put one of these in and so it's not integrated with their business partner supply chain. Financial control is also an issue as well as group dispatch management. So we want to make some significant changes here, right? And DDB looked around and they said, well, what are these evolving industry standards that we can leverage? And what they found was that there was a group called MAMOSA. Now MAMOSA is an alliance of operations and maintenance solution providers and companies who are focused on developing this capabilities that allow you to have an integrated supply chain manufacturing process. So all the way from build to deliver. And they define the different data structures and XML specifications necessary for the industry. They also have implemented what they call an integration architecture. We'll see. So in finding MAMOSA, they said that this is a perfect opportunity for us to become aligned with MAMOSA and implement OSAEAI, which is the open systems architecture for enterprise application integration. And they believe that this is a way they can actually advance their transformation by using these industry standards in a way that's going to be game changing. Now that's all well and good, but they had to have some sort of reference architecture against which to implement their transformation. And what they found was that Capgemini and IBM had come up with MAMOSA Manufacturing Industry SOA Reference Architecture. And they really found that the reference architecture and the requirements and the steps that were laid out and the actual consulting there, maybe that was behind it, was all something that resonated with their business leaders and it made it clear as to how they actually might be able to transform. Now they also knew they had lots of work to do across their organizations to make this transformation necessary. And they knew it had to become stepwise, otherwise they were going to fail, stepwise and evolutionary. So here is actually, this is not an imaginary case study. There really is a paper out there that Capgemini and IBM led, which speaks to the implementation of SOA using MESA standards. So you can look it up at that link, hopefully. So our strategic direction is we really need to focus on this group dispatch management solution. The business process services and infrastructure that will make up that solution. And we have to form a solution platform, I'm sorry, a services platform that can also support other solutions such as order management and production management as the industry moves to these open standards. So they're going to embrace MESA, they're going to actually use the IBM Capgemini reference architecture. But how are we going to achieve that? Well we're going to adopt OSIM, we're going to actually do an OSIM assessment on DDB. And we're going to use that as a method to help bring together our line of business stakeholders with our IT stakeholders to ensure they understand what is necessary for them to transform their business. So this is a mind map I came up with. This is not actually part of the original OSIM specification. But here it is in this presentation, use it as you see necessary. We decided we needed some way to visualize how all these pieces and parts of the assessment and OSIM fit together. So you look on one end, the left end you have EA and SOA strategy. So we've defined our enterprise architecture and SOA strategy and you have to have an enterprise architecture or some sort of business transformation strategy as the starting point for doing any OSIM assessment. If you don't have some sort of visionary transformation objective in mind or if you don't have an enterprise architecture which defines all the pieces and parts of your organization and how they fit together, you're going to have a hard time adopting OSIM. Now on the right hand side what we have is essentially the model itself, the OSIM model and the maturity indicators and the base indicators that we use and will modify as we move forward. Now the assessor collaborates with the organization which determines the enterprise architecture and SOA strategy and informs the target SOA maturity model. So what are SOA strategy and the SOA strategy and the enterprise architecture constitute our target SOA maturity? And it provides this input into the assessment report. And the assessor is responsible for customizing the maturity model, the maturity indicators and determines the current SOA maturity and uses that as input into the assessment report as well. Eventually we're able to describe a SOA roadmap for implementation and adoption. So let's talk a little bit about maturity indicators and attributes. In the model itself you have many different indicators. They're like guideposts that help you understand by level what observable elements of maturity are necessary for us to achieve that particular level of SOA maturity for that dimension. So in this case we have, I'm showing here maturity indicators for the business dimension and a componentized or level three business maturity indicator is in the base model, formal definition and documentation of the organization's business drivers and processes. Now for each maturity indicator or guidepost you have a set of attributes. A set of attributes lead you to make a decision about or determine the maturity level within that dimension. So in the case of this particular example there are cross-organizational maturity attributes at level three componentized and here it says some formal enterprise architecture constructs exist and the organization's business drivers are documented as cross-organizational business objectives. Exactly what that means to Dursley or to your organization is part of the customization of the model. So the maturity indicator is a service capability of the business or IT organization. It's associated with a specific service maturity dimension and it's the focus of the assessment. Now again the attribute is an observed characteristic of the maturity indicator and maturity attributes are observed capabilities of the target assessment organization which by the way you customize and we'll go through that. So within the OSIM model there is a set of assessment questions that help drive us to determine which attributes of the maturity indicators are most appropriate or aligned to our specific organization from the as is view. And that also helps us guide the decision as to how we're going to construct our roadmap for the 2B as well. So in this particular case the business dimension and assessment questions are listed here. Some of them are what are the major business drivers for this initiative? It goes on down to what are the metrics for return on investment, so on and so forth. And they are intentionally open-ended because if you get down to a yes or no question when you're working with your stakeholders and you're going to bring everybody together probably you're going to bring everybody together in the assessment process in the organization, the business stakeholders, the technology stakeholders, the operation department, the programmers. And you're going to ask them these questions in order to gain as much information as possible to make a recommendation about the current maturity level and where you believe and the roadmap that can help them achieve their desired vision. So it's important if you do customize the model that you don't customize it in such a way that you ask assessment questions that are yes or no answers, right? That may help to a certain degree, but a yes or no question doesn't drive a discussion which will help uncover some of the underlying challenges for implementing a particular service. So here we have the method dimension and you can see the maturity indicator at composite services or level five which is service-oriented modeling. The maturity attributes of this particular indicator which is the formal use of a SOA, architectural design, construction, and deployment methodology for the implementation of services is utilized, right? Some of the maturity indicators to lead us to believe that we are at maturity level five would be a formal and recognized methodology for the creation, development, deployment, and management is in practice, right? So we're using the attributes as guideposts themselves to determine from the information that we glean as part of the assessment where on this, you know, matrix our organization fits, right? So it's important to customize the framework to reflect the overall services strategy, right? And the maturity indicators are there to focus on alignment of EA vision, industry standards, for example in this case Mamosa and Mesa use, internal enterprise architecture standards and techniques, SOA standards in general, and enabling the service location transparency. Our assessment questions, just a review, are intended to identify the SOA maturity attributes of the assessed organization, right, which help us determine what maturity we are currently at. For example, if we wanted to extend the model in this case for our DDB example, the current base model indicator for the business dimension is the SOA maturity assessment of the OSIM business, I'm sorry, the SOA maturity assessment of the OSIM business dimension is conducted by identifying the formal definition of the documentation of the organization's business drivers and processes. Now we can extend this by adding standards requirements, standards adoptions, in this case maybe Mesa or OSA EAI. And so this may be SOA standards specifically, specific standards that we think are necessary in order for us to achieve technical direction or industry standards. It could also include for example outsourcing services or using cloud computing. Now in our case, we've decided to modify the business dimension maturity indicator as follows. We've actually placed in the maturity attributes, new attributes which lead us to make some particular decisions about what maturity level we're at. This is necessary for DDB to understand current adoption and approach across all of their organizations for the implementation of SOA, and particularly SOA in the context of their industry standards, Mesa and OSA EAI and the implementation of the reference model that we talked about earlier. So here, for example, if we look at, let's see, componentized at level three, the indicator is formal business process definition for implementing the most business flows, right? And we are going to make a distinction about the particular component that we are evaluating or organization or department, and we're going to say that the cross organizational behavior would be measured by seeing or verifying and validating that the organizational acceptance of MAMOSA or Mesa vision is in place and that the strategic planning is in the process of being conducted, right? So it's evolving and the business components are not integrated into the value chain, right? So in this case, you know, componentized is not really where we want to be. We certainly want to be probably up near composite services. So as we, you know, go up in maturity or in adoption of MAMOSA and Mesa standards, we're going to see at level five that MAMOSA and Mesa EAI is defined in terms of BPM flows and that the organization or DDB, in this case, our business drivers are elements of the overall global business value chain. So we're actually seeing adoption of this particular implementation of Mesa in context of our EA and we're seeing the actual adoption across our business through the transformation of the value chain. So if we look at the architecture dimension, the base model maturity indicator was identifying those service components that have been designed and are deploying using formal SOA methods, principles, patterns, frameworks, or techniques. And we're going to extend that in this case by saying that, well, from a standard point of view, that service components are designed using Mesa industry best practices and industry SOA reference architecture models that implement the MAMOSA standards. And then from an outsourcing point of view, because we have an outsourcing strategy with respect to our case study, that service components are designed to allow substitution of outsourced services, right? So we don't get, you know, basically into a situation where we're only able to implement services that are developed internally. We can actually outsource them and that is, you know, the value in the global value chain. So as we see here, and we'll go back, I thought there would be a little red circle here. We have the architecture dimension and the model that's been updated. Now with our new maturity indicators and our new maturity attributes, which lead us to determine what SOA maturity level our organization is able to achieve. And if we look at SOA or level five, again the maturity indicators, service components are designed into Mesa industry best practices and industry SOA reference architecture models that implement the MAMOSA standards. And the integration, and we're seeing this, you know, integrated throughout the enterprise. It's integrated enterprise wide. And, you know, the primary attribute of that that we would need to verify would be most systems are using Mesa SOA reference architecture based on implementations that have implemented MAMOSA standards for internal interoperability. So, you know, as we were to go through our assessment, or in this case, reassessment of our organization, we would find evidence that our applications and our business are actually being managed to this particular maturity indicator as defined by the maturity attributes. So, you know, as part of this, if we were a practitioner and working with the business, consulting with the business to determine what the maturity ought to be, the 2-V state, right, the vision, we've determined that in our case for DDB, we have to be at, we want to be able to achieve dynamically reconfigurable services at the business view or at the business layer. And that we believe because of our outsourcing model that internally we really don't need to achieve more than level five for internal services, because if we outsource, you know, significant sections of our business to other business partners that will take care of the ability to do dynamic reconfigurable business services, that may or may not be an assumption that works out, but that's the assumption the business makes here in this particular case. Now, when we did our original OSIM assessment, we found that the business that DDB was at these maturity levels for across the different dimensions, right? So, their applications are pretty siloed, and they're using layered architecture and some componentization, but, you know, really they're back down at the old object-oriented modeling techniques and not really using it in a service-based method. Now, their operations department a little bit more mature. So, now we can actually define the roadmap, and this is where a little art comes into play. Now, we have in the OSIM document, you know, the value achieved or the business value of achieving each particular level, but you have to, as a consultant, kind of determine what will be the value of achieving each maturity level with respect to the mission and vision, right? In the case of DDB, we've decided that we're going to need to have dynamically reconfigurable business processes, and, again, our outsourcing strategy is probably going to take that into consideration, that internally we probably won't be able to get our development and IT team to become at least initially more than SOA-enabled or level five, because we got a long way to go here anyway. So, we're looking to outsource, you know, initially. Internally, we're going to do a lot of training and infrastructure modernization in order to achieve level five, and then we're probably going to go through a set of incremental steps of reevaluating using OSIM to determine whether our strategy is working and to determine next steps that may be necessary in order to achieve our vision. So, this is a good point to actually talk about conclusions and then go into discussion. It's really important to customize OSIM. You can certainly use the base model. In fact, you might want to use the base model initially to gather information and make an initial decision about where in the maturity matrix your organization lies. Now, remember that when you are doing an assessment that it's context sensitive. You're going to be getting information about maturity with respect to the organization or application business initiatives that you're focused on. You could do this enterprise-wide, but you kind of get an enterprise-wide high-level picture out of that. If you go down to a specific initiative and you really drill down into the groups that are the stakeholders on the business side as well as the IT side, you get a more granular picture. So, you need to customize OSIM to focus on, you know, your EA strategy but also industry standards adoption, internal enterprise standards, implementation of techniques, certain techniques like the implementation of virtualization for implementing cloud computing may be one of yours. So, a standards alignment of the EA vision, as I've said, and OSIM assessments can be used to help refine organizations' services strategy and approach. This is a technique, it's a framework, and it's there for you to modify as necessary. So, Heather, I think we probably have some questions on tap, as if Heather is still online. So, let's see here. Q&A. All right. So, we have one really good question that's been generating a lot of traffic on the chat, and what's the relationship between OSIM and IDLE? The relationship between OSIM and IDLE. So, ITIL, if I heard that correctly, is really a set of best practices and techniques and approaches for implementing your operational infrastructure mostly, right? And they kind of go hand-in-hand when we're looking to implement operational best practices as part of your SOA implementation. So, I think if you look at the model at the original matrix, and we'll go right up here to the example here with Dursley Drillbit, ITIL would be one element potentially for your organization to consider when defining maturity and loading the model with respect to the infrastructure and management layer. So, it may be that you want certain ITIL processes or techniques to be used as, across the organization, as part of your vision, right? We know that adopting kind of all-for-nothing strategy is probably not going to be successful. And what you can do is actually load the model in an incremental fashion so that as you adopt services and go from the service foundation levels to through services and all the way up to level seven, that you're implementing or you're seeing the implementation, you're actually witnessing the implementation of certain ITIL techniques. So, I see that they go hand-in-hand actually. Heather? Thank you, Andra. Another question that we've had online is why are base assessment questions open rather than multiple choice? Oh, well, I thought I went through that. Well, if they were multiple choice, you just kind of get yes or no. But remember, this is a consulting technique, right? And the more information you have, the better off you're going to be to make decisions about how you effectively implement your SOA strategy. So, you know, when you're going through this process, and I've gone through quite a few of them using OSIM, you're going to be working with different stakeholders. Now, let's take the business stakeholders, right? You might ask these open-ended questions. Can you give me, for example, a document which defines your strategic vision? Well, you would not imagine how many customers that I've had that kind of looked at each other like, oh, we don't really have a document. I mean, we've got one power point. Well, we've got a couple of power points, too. Well, yes, Bob. But I mean, we've got the whiteboard thing. I mean, so really, when you see that, you know that they haven't sat down and agreed amongst themselves what their business strategy is. So, certainly, you wouldn't put them up at level seven if that's the case, right? And that would help you understand, well, you know, they maybe need to define a well-agreed-upon business strategy. And that business strategy's got to define the business process that they plan to implement. And again, you would not believe how many customers and organizations don't understand the business processes that they plan to actually implement in their IT systems. They just haven't really considered it. They know that they have an initiative. They can see the end game. They just haven't actually thought out the process for implementing the business process. Heather, we have another one? Yes, we do. So from Simon Finney, is there any experience of CMMI-focused organizations moving into a solar environment and how they adopt OSIM? Well, you know, we believe that, and this has been asked of us before, you know, why didn't you just use CMMI or, you know, why is this another maturity process and so on and so forth, right? So we found the need to implement OSIM primarily because we want to scope the definition and process for assessment, right? I'm sorry, the definition of SOA and the process of assessing the target organization. And so with CMMI, it's a very broad approach, right? And it's important and it may be used in context with OSIM. So you might have CMMI being used side-by-side with OSIM as a way to determine implementation maturity. But, you know, when we focus on SOA, quite frankly speaking, there's more to IT and the business than just implementing services. And what we're going to be doing when we focus on an OSIM assessment are on those high-value targets that are going to help achieve our business mission or vision. So we found that this really helped define or better defined the scope in the context of implementing services or cloud computing than simply going to a more broader model. Heather, we have another one? Yes. We've had a question on the time dimension. The concern of an assessment on the time of an organization needs to step from level N to level N plus one. Right, so how much time does it take? Time is not actually integrated into the SOA assessment process and it's not integrated into OSIM either, really. These are snapshots in time, right? So theoretically, if you did a snapshot day by day, which we know you're not going to do, right, you would see a continuous migration from one particular maturity level to the next over a long period of time. Or a short period of time if you decided to outsource pieces or do a Greenfields implementation. It's really dependent upon how you decide to approach your SOA or cloud computing strategy. So time is really dependent upon a bunch of different things, right? So one is your enterprise architecture, your business mission and vision, your techniques that you're applying. And OSIM is there to help you actually make a decision about where you are from a maturity point of view to determine if you're going in the right direction at a particular point in time. So I would suggest, and it is a good point, that you reassess at very important milestones, right? So you set up this maturity roadmap and the roadmap is broken down into project attributes and timelines and within that you would actually do additional maturity assessments to determine if you're making progress. Now, you know, I've got to be honest with you. OSIM probably is most valuable to the enterprise architects and the executives who are seeking to oversee the transformation process. On a day-by-day scale, the average developer or IT guy probably isn't going to see a lot of value from OSIM because they're making very small incremental adoptions in order to get from one maturity level to the next. But it would be a great dashboard tool, right? Thank you, Andres. The next question we have is how to determine the best scope. Most companies have different maturity for business units. Oh, absolutely. As I said during the presentation, you want to scope this down at a level of granularity which is going to give you some actionable results. So I would say that you take your SOA vision or your cloud computing vision and you go by service, right? And you drill down into each one of those services and do an assessment with respect to the stakeholders that are supporting the implementation of that particular service. So if you did it across your entire enterprise, you might not get any actionable results. If you did it by service, then I guarantee you probably would. Now, if you go back to the well and it's the same folks every time that you're assessing, well, that could be an issue, too. So you might want to do, you know, if it's the same individuals you're having to assess, you might want to have an assessment session that focuses on different initiatives and you break the different roadmaps down by initiatives so that you don't have to go back to the well and these stakeholders every single time. Thank you, Andras. I think we have time for one more question. How does this work with Togaf? Do they overlap? Well, Togaf is, you know, the primary methodology in the open group for addressing enterprise architecture, and it is, you know, worldwide most recognized method. It would be the methodology that you would adopt for implementing your enterprise architecture and there are kind of hooks down into implementation architecture. So I see this as, you know, OSM is absolutely part and parcel of the process you would use to apply in your implementation phase as you go around the crop circle to determine your as is to be. So it would inform your strategic vision. It would inform your business architecture and it would inform your development practices and processes and all that kind of stuff as you made it around to deployment at the top of the, you know, when you went from 11 to 12. So I actually think it's a perfect tool to use when implementing Togaf, especially when it comes to cloud computing and service-based implementations and visions. You know, Heather, I bet you that some folks are interested in maybe tooling. So if I were to, you know, I've had this question before, so I, you know, since I wasn't asked the question right up front, I'll go into it myself and that is that, you know, do you see tools to support or do you yourself use tools as an IBM organization or do you see customers using tools to help adopt OSIM? And absolutely we do. We see their organizations like Capgemini. I know that IBM has a tool. I know SAP has got a SOA assessment tool. All of these organizations are certainly approaching modernization in different ways. But we have a SOA or, I'm sorry, an OSIM assessment tool we call ART, which is the SOA Assessment and Roadmap Tool. And it helps us actually gather all of the information as we go through the assessment process and then effectively visualize the results of the OSIM assessment when we're working with customers. So we're really hoping that other vendors or customers take up the mantle and look to actually operationalize these assessments as well. Is there anything else? No, I think we're out of time for this webinar. Andres, this has been very interesting. And I think the questions that we've had come in have been very insightful and thoughtful as well. So I want to thank the audience for the excellent questions.