 Hello everybody, I'm Chris Harding, I'm the Open Group's Director for Interoperability and it is my pleasure to welcome you to this Open Group webinar on using TOGAP to define and govern service-oriented architectures. SOA is a key enabler of interoperability and we have had a workgroup on SOA in the Open Group for some years now. From the inception of that workgroup it was recognized that the key value, the largest value that it could deliver to the architecture community was to give advice on the use of TOGAP for SOA and that was the subject of the practical guide, the guide to using TOGAP to define and govern service-oriented architectures that we published a little earlier this year and which is the subject of this webinar. The webinar will be presented by Ed Hinton of Architecting the Enterprise and he will explain the use of TOGAP for SOA as covered in the published guide and we also have other experts on the panel including Steve Bennett of Oracle. Once the presentation is complete there will be a question and answer session in which experts will try to answer any questions that you may have. If you do have a question and please think as we go through the presentation about anything that needs asking about, if you do have a question please could you use the Q&A facility on the WebEx to put that question, asking the question, making it visible to all participants so that everybody can see the stream of what is going on. I see we have been joined by Ewa Vico who will also be a panelist and who is from the Bank of Montreal and he was one of the co-chairs of the project that developed the practical guide. Without further ado I will hand over to Ed who will take us through this part of the presentation. Just some logistics Chris first. I've got an email message from Dave Hornford who is trying to get on as a panelist. He is on as a regular attendee but not as a panelist and Matt is apparently trying to get on as well. Two of our additional panelists. Could you repeat those studies again please Ed? It's Dave Hornford and Matt's, I'll spell his last name. Matt Scenival. Scenival. GEJNAV. And Dave will be in fact giving a part of the presentation once Ed has been through the first part. Sorry, just the second day with our list of panelists. Okay, so perhaps we can sort that in the background Simon while Ed gets started. Okay, that's fine. All right, shall do. I'm a trainer and a consultant with Architect Me Enterprise and that's the extent of my marketing for this. We're going to talk about something that a number of us put together looking at using Togaf to divine and govern service oriented architectures. Why enterprise architecture and SOA? Well much of the work that has been claimed to be done as SOA over the last few years has really not been SOA. It has primarily ignored the A in SOA, the architecture piece. And we've ended up with a proliferation of web services. So one of the things that we're trying to emphasize by linking together SOA and Togaf is the A, the architecture piece. So we're trying to avoid the scope of SOA being just individual projects, just individual web services. We're trying to get a consistent use of SOA across the enterprise. We're trying to connect SOA to the bigger business problems, not just the little web services that proliferate quite readily and easily. Obviously one of the big things that Togaf talks about is reuse and SOA is probably one of the best and major candidates for reuse. It's one of the things that SOA has touted to be, but it also costs quite a bit. The infrastructure to support SOA from ESBs and directory services and all of this stuff costs a lot of money and you need justification for that investment, which will eventually we hope end up delivering the expected business value that SOA has been touting for five or six years now. So for those of you who don't know Togaf, who aren't familiar with Togaf, we're not going to be able to teach you all there is about Togaf in less than an hour, but it's a detailed method for and supporting tools for doing enterprise architecture. It is a compendium of good and best practices that have evolved over 15, 16 years. It's used by 80% of the Fortune Global 50. Most impressive, there are more than 15,000 certified individuals in Togaf. What we're going to focus on is what is the core of Togaf. The core of Togaf is the architecture development method, the ADM, which breaks complex processes of architecture development into hopefully a number of simpler, smaller steps called phases in which the architect actually considers different aspects of the overall problem. The guide in a nutshell, what is it all about? Well, it's adoption of the Togaf ADM to SOA. It's trying to take a best practice view of SOA in all the ADM phases to manage the concerns of the SOA stakeholders. One of the things that Togaf really focuses on is how you manage and address your stakeholder concerns through views and viewpoints, through artifacts that you deliver that hopefully will address the concerns of your stakeholders. It is an adoption with an extension of the Togaf core current metamodel for SOA. We've extended the metamodel in a couple of areas, just particularly for service-oriented architectures. We've also looked at doing SOA at different architectural levels. Togaf talks about the strategic level, the segment level, and the capability level, and so what we've done is approached SOA from those same three levels. We've also tried to connect the practical guide, Togaf, with other work that the workgroup has developed and either has delivered as standards or is in the process of delivering as standards, such as the governance framework, which is a standard, the maturity model, the open group service integration maturity model, the reference architecture, which is about to be published as a standard. We're hoping that that will happen next month in October. We're working on SOA and security, and with this one we're also working with the cloud as well. A phased approach to SOA, and Togaf has nine phases that go from a preliminary phase to all the way down to phase H, architecture change management. In the preliminary phase, you're basically setting up the infrastructure for doing enterprise architecture or for doing SOA in this case. You're establishing things like governance, your principles, things like that. Phase A, the architecture phase, you're establishing specific SOA projects that would hopefully go across the organization from an enterprise perspective. What you're really doing in the architecture vision phase is establishing a vision for what you want to do and getting the sign off and budget to actually go ahead and do the work. Then you have the architecture development phases, which are phases B, C and D, where you take a different perspective on the architecture that you're developing. Phase B, you're looking at it from the perspective of the business. Phase C, you're looking at it from the perspective of applications and information. Phase D, you're looking at it from the perspective of technology. Then phases E and F, you're actually going ahead and doing your detail planning, getting ready, working with the project management office to get what you've planned out, what you've architected, implemented. Phase G, it's being implemented and you're providing governance over it as the implementation takes place. And then in phase H, you're keeping it fit for purpose. So in a little more detail, the preliminary phase, you're doing basically four or five major tasks. You're setting up the infrastructure, as I said earlier, to actually do enterprise architecture and enterprise architecture in terms of SOA. So you're establishing principles and in the guide, we come up with an additional principle and that's the principle of service orientation and that's defined in the guide itself. By the way, the guide is freely available. I think you just have to register for it at the Open Group website in all of its detail. You're looking at, is the organization really ready to do SOA? And the Open Group Service Integration Maturity Model is a 7x7 maturity model. I'm sure many of you are familiar with standard maturity models. This is 7 levels of maturity and 7 areas of measurement of those levels of maturity. Then there's the Open Group SOA governance model where you can take and adapt your own internal governance for those aspects of SOA that are important from a governance perspective. Another thing you do in the preliminary phase is you adapt TOGAP to your organization. No one takes TOGAP out of the box. TOGAP is utilized as it best fits with the individual's organizations and the organization takes from it what will provide added value. And one of the things that we've done is we've come up with a high level SOA reference architecture that will help you adapt TOGAP to do SOA. And finally, we talk about establishing the initial footprint of the organization as a SOA center of excellence. This is the adaptation in what we're saying, the TOGAP style of the TOGAP metamodel for SOA. We have added, in essence, I think four individual entities to the standard TOGAP9 metamodel. And those entities are an information entity in the business architecture, which talks about information communicated about within the business, and an information component, which is a grouping of individual information entities, again from a SOA perspective. We've added an IS service contract in the applications area of the metamodel. We have a service contract in the business area of the metamodel, but this is the IS service contract between the consumer of the IS service and the provider, and it establishes the functional and non-functional parameters for interaction at the applications level. Then we've added a depiction of the actual SOA solution. Then we have two other areas, service quality and location, which exist in the current metamodel, but we've emphasized for their importance. Service quality, the object is used as an attribute to services, components, and contracts, and location becomes very important for understanding where the services are available from. So, stepping through the preliminary phase, and I'm going to quickly go through each of the phases for you and talk about anything that has changed in the phases for SOA in particular. We'll talk about are there additional objectives in the phase? Are there additional inputs? Are there additional steps? Are there additional outputs? If we look at the preliminary phase, we're looking at objective is ensure SOA supporting principles are in place as well as SOA governance. On the input side, we're looking at the SOA reference architecture, as previously mentioned, as well as the maturity model, the SOA governance framework, and any industry best practices around SOA. The steps are not changed per se, but we've just emphasized SOA aspects. So, you're identifying your stakeholders concerns from a service orientation perspective. You're defining the scope. You're ensuring the scope is SOA appropriate. You're tailing your deliverables to the level of architecture that you're developing. You're evaluating your own business capabilities, are you ready to do SOA, and you're confirming your principles. And then on the output side, you'll end up with a statement of architecture work with SOA as an approach. You'll end up with your updated architecture principles, a capability assessment, a vision for doing architecture with SOA-based thinking in it. It didn't have additional content that will populate your architecture repository. So that's the preliminary phase. Phase A, you're actually starting to do individual SOA projects. Now, these projects could be of a strategic nature. They could be at a segment level, or they could be at a capability level. Most projects of this type, however, are really done at the capability level. So what you're doing, what you're trying to do in this phase is ensuring that you've got all the information you need to go ahead and get appropriate sign-offs and budgets to do the projects that you want to do. So as inputs, you've got everything that came before, everything that was done in the preliminary phase. The steps, you're identifying specific stakeholders for these SOA projects. What are the SOA special concerns that might exist? You're defining the scope of the projects. You're evaluating your business capabilities. Again, are we SOA ready? And you're confirming your principles that you developed in the preliminary phase. The outputs, you hopefully will have a signed-off statement of architecture work with SOA specifically as the approach that you're taking. You'll have architecture principles, your capability assessments, your vision, all of these confirmed for the individual projects that you are envisioning doing. Then we move on to the actual architecture development phases, phases B, C, and D. In these, we're doing architecture work but from four different perspectives. We're doing it from a business perspective. We're doing it from an application's perspective, from an information or data perspective, and from a technology perspective. What you'll see here is in addition to the objectives and the input phases and outputs, and I'll advance the next slide, we'll talk about specific artifacts that you may want to consider to address the concerns of your stakeholders. Going back to the phase B enhancements, there's no additional objective material. However, we look at things like the organizational model where you've got the SOA Center of Excellence. You've tailored your architecture framework. You're using it here now. These are all inputs. The steps, you're going to select reference models, viewpoints, tools, artifacts that you're going to develop to address the concerns, specifically of your SOA stakeholders. As outputs, you'll have gone back and validated your principles again. You'll have a target business architecture. You'll have a baseline and target business architectures. You'll have a gap analysis from a business perspective and you'll put together a roadmap. The outputs may include some of the diagrams listed here and if we go on to the next page, we talk about some of the artifacts, some of which exist in TOGAF today but would be modified specifically for SOA. Some of these are new. For instance, the business vocabulary catalog. That is new. The business service location catalog is not new but it has more emphasis on location since you want to know where the business services, where the SOA services are located and how you access them. Things like an event process catalog is not new but the business service information matrix is new because information is a new entity within the business area of the metamodel. This just gives you an idea of some artifacts, their purpose and what metamodel entities are utilized in those artifacts. You'll see for the rest of the phases in the ADM, we'll take this approach. We'll start with basic, what are the enhancements from an objective input step and output perspective and then we go on pretty rapidly to what are the additional artifacts. This publication or this presentation will be available and Simon will let you all know how that will be available at the end of the... at the end of the presentation. And it's also, all of this content is within the actual publication, within the practical guide publication itself. So in phase C, you're looking at both applications and data and we've extended the application section to include applications and services. Again, the inputs are everything that has gone before, including the business architecture, as is and to be gaps and roadmaps that you've developed in the previous phase B. The steps you go through are basically the same as you went through in B. You will look at your reference models, your viewpoints, you'll develop your specific artifacts to address the concerns of your data and applications and services, stakeholders. And you'll come out with a, as is, a target, gaps and roadmaps from both a data and applications and services perspective. And so we go on to the phase C artifacts and we talk about things like a service integration diagram. That is new. Business process, IS service matrix, which is not new. So again, we have a mixture of some new and some existing artifacts that are called out by TOGAP, but they're really targeted in this case for service orientation specifically for SOA and the development of SOA as architecture. You have a logical SOA solution diagram. You have an IS service distribution matrix. Moving on to phase D, there are really no additional objective materials, but phase D is going to be very important because here we're talking about the underlying infrastructure that is needed to support SOA. So here you're going to have things like enterprise service buses, UDDI directories, if you're going standards-based, things that may not exist in your current technology base, which you will need to have in place in order to support your SOA focus. So again, everything that's gone before is an input, including all the work you've done in the business architecture as well as in the data and applications architecture. The steps are again similar, however, with an emphasis on SOA. Here we have, however, a... have developed within the open group SOA workgroup a specific service-oriented infrastructure reference model. That reference model, Togaf 9 says that to do technology architecture, you really should have a technology reference model. Togaf suggests one, but it's been around for a while and needs updating, so what we've done for SOA is we've actually come up with an infrastructure reference model for SOA, and that is in the process of being published momentarily. I think and hope it's going to be published in October. And then your outputs are again, you're going to have an, as is to be, technology architecture perspective that hopefully will deliver the business value that you've identified in Phase B. And only two new artifacts here, a logical technology architecture diagram and a logical application and technology matrix. Moving on to Phase E, Phase E, you're basically getting stuff ready to be built. Here is the first phase where you're actually concerned with how this service-oriented architecture is going to be put in place. The objectives of Phase E, there are nothing new here. As you would expect, all the architecture development work that you did in phases B, C, and D are inputs, including the separate gap analyses and roadmaps. In Phase E, you will take the gap analyses and roadmaps and you'll consolidate them and rationalize them. And that will be done again here from a SOA perspective. And you start really talking about what is the SOA solution that is going to be developed. So the steps include what reference model viewpoints and tools do I need to create? Where is my physical data component? What are my physical application components? What are my technology application components? And what's the SOA solution that we're targeting? And as outputs, again, we have a list of potential artifacts that you may include, the SOA solutions matrix, the SOA solutions diagram, et cetera, that we show in the Phase E artifacts. Many of these are new, especially when you get down to a technology guidelines and application guidelines. Those are brand new call-outs for doing SOA in TOGAF. That is it for my piece of the presentation and I think I just about got it on time there. Chris, are you still with us? I think we may have lost Chris Harding. In any case, Simon, I need to turn this over now to... Yeah, Chris is back on. Hi, Chris. Sorry about that. I dropped off momentarily. Dave Hornford, in fact, will be taking the next slides, I think, since he has joined us. Dave, perhaps you could introduce yourself briefly and then explain about the importance of the changes to the metamodel. Certainly. I was wondering if Ed could keep control of the slide deck for me, it would make my life easier. Simon, if you give it back to me, I'll do that. Thank you. You ready to go, Dave? Yeah, ready to go. Can you go to slide 21? While Ed is moving to the metamodel, my name is Dave Hornford. I'm the chair of the Open Group Architecture Forum in terms of open group activity. I was co-chair of this project. And the senior partner for architecture for Conexima Consulting firm. What I'm going to talk about is the underpinning metamodel of what we need to describe in order to describe an enterprise architecture. For the Servants-Oriented Architecture Guide for TOGAP, the core of it are the entities and the relationships of the entities that are required to be described. What's being shown is that TOGAP out-of-the-box metamodel with a set of entities, role process event, service quality contract, and so forth, highlighted. Those entities exist within TOGAP today. What they do, what we're highlighting, is that those entities are very important from the perspective of doing SOAP. There's a shortage of what we need in order to properly describe our architecture. Ed earlier showed a slide which looked like this that had a few extra entities, which he identified added on. Those entities were the ones that were missing. And if we go to slide 22, we see a slightly different view, which is a UML-like relationship of the different entities. And they're color-coded so that in yellow we have business architecture. In green, we have applications architecture, and so forth. The ones that have the dashed box around them are the entities that were needed to out the comprehensive description. This slide peels off all of the other entities. It's not to suggest that those entities are not important. It's that these ones that we're highlighting for the purposes of doing service-oriented architecture. There's also, if you read the guide, an underpinning assumption that standard motivational elements, your strategy, your drivers, your objectives are included and are aligned to every one of these entities. What I'm going to spend the next two minutes is going through the different pieces in a little bit more detail. So if you can go to 23-Ed, and we'll zoom in close enough so that it's almost legible. It's there, Dave. I know. When we're looking at what you need to do to describe the business architecture, the minimum components that you have to describe in order to do service-oriented architecture, the center of it are business services. What are the services that the business delivers, which will consist of different processes? Once we understand what our business is delivering, what are the processes that are used to deliver those services? What are the events that trigger the processes? Who the actors are that deliver the services? We're in a position to move forward and actually understand the underpinning IT asset required to deliver the business. What was missing inside Togaf in the description in business was information. We've got the business services, their quality, their location, who performs them, what triggers them, what are the underpinning processes? And what we added in, which is at the bottom of the slide with the dashed lines around it, are the information entities and the information components. What is the information that needs to move around in order for the processes and the services to be delivered? And at this point, we're talking about information. We're not talking about data. I'm going to be very clear that there's a distinction. Processes, services, actors use information. They don't use the data elements. If we move on to the next slide, number 24, when we start talking in Togaf terms about the information systems architecture, our applications and our data, now we're in a position to draw the linkages between our data and the information a process or a service consumes. There's also a direct linkage from the business services to the information system services. And in both cases, we're keeping track of subordinate entities. What are the measures? What are the qualities? Where is this happening? Because if we have an information, a business service, and it happens in my country, Canada, that locational information becomes very important when we're delivering the underpinning information system service. And those underpinning system services require a contract in all cases. What is the terms of use? What is the terms of provision? What is the service provider signing up for? And what is the consumer signing up for? So that we're able to build out the architecture that supports what the business is trying to accomplish. Underpinning the metamodel is the logical application components because at the end of the day we have all these services. Something has to deliver them. Same regard that we have in the business service, processes and actors deliver. Logical application components deliver. And our information must be processed by those logical application components as data elements. Moving to number 25, slide D, or page D. What are we chasing in our minimum architecture entities that we have to describe? What services are provided by the platform? What does our infrastructure provide? Are there location services? Are there directory services? Are there message transformation services? Are there security services that are going to be realized by those logical technology components that will support and deliver those logical application components? Again, managing that abstraction from the service to the logical components so that we're able to move forward. There's nothing new added in here. This is standard out-of-the-box enterprise architecture. And a good enterprise architecture readily delivers good infrastructure. The biggest changes of our spend a bit of time is in phase E, slide 26. And here, from the purposes of providing guidance to delivering service-oriented architecture is where we made, in many regards, the largest departure from out-of-the-box Toga. Suggest that the physical data components, physical application components, and physical technology components are described in phases B, C, and D, respectively. You're describing your data and your applications as part of the applications architecture, and your technology as part of the technology architecture. What we suggest for the best development of service-oriented architecture is a modification in moving those descriptions and understanding the physical realization to phase E. In Toga's phase E, it's called opportunities and solutions. And the core deliverable from this is understanding what it will take to realize the target state. What is the roadmap? Any time we're looking at realization, we're looking at the real world. We're looking at the physical components that have to be implemented and describing them here, whether it's physical data, physical applications, allows us to isolate when we're doing architecture work the conceptual and the logical work we're doing in phases B, C, and D. From the physical realization, architecture we're doing in phases E. Design work still is later. But at this point, how does this pin together and the added-on element that needs to be described as a solo solution because we need to keep track of our services, our information systems services logically, and we need to keep track of a solo solution that is realized by different physical components. And that's a new addition, which allows the practitioner to then come out of phase E with a clear concept of how the target will be realized. And the important thing to realize and do as you're working your way through this is that each of these entities may need to be described in a current state and a target. Where do we want to get to? What will it take in order to realize the vision that was identified in phase A? To meet the objectives of our stakeholders, to meet the strategy of the business. What is the target, phase E, lining up the physical components that need either to be developed, changed, or eliminated to realize it and keeping track of the realized solutions? That's a quick walk through the underpinning of the metamol. And the key guidance from the practical guide is be very clear about what you need to describe and how you will describe it in order to understand your architecture so that you can realize the objectives of the business. Thank you very much, Chris. I'll pass on the baton to our next person. Thank you, Dave. And in fact, we have now come to the Q&A part of this webinar. We have a number of questions posted online. And please, if people have other questions, please use the Q&A feature of the WebEx to put those questions to the panel, making them visible to all participants so that everyone can see what the questions are in fact. We can start with a couple of the questions. Don't need an answer from the panel. They were questions about where is the practical guide itself available and about the presentation slides from this webinar, where will they be available. I posted an answer to the first of those with URLs for where you can retrieve, obtain a copy of the PDF if you want to download that or where you can browse the HTML version of the practical guide online. And also given the general location where you'll be able to find the presentation slides, Simon will be sending email to everybody with the actual URL after the webinar. So perhaps we can then move on to a question perhaps the best one to start with is the one from Gleod and the Johnson. Is there a summary of how many TOGAP changes were made? A summary of changes will be useful. And perhaps the three panelists who haven't yet spoken could start with the answers to this. And perhaps if you could just give yourself a little bit of a brief introduction when you do so so that everyone can understand who you are. So, AWOL Steve and Matt, do you have any thoughts on the best way to find a summary of the changes? I'll step in here. This is Stephen Bennett. I'm a senior enterprise architect at Oracle currently focusing on SOA information management and cloud computing. We don't have a one pager of where we've actually made changes. What we have done in the document is literally highlight in the appendix the changes we did by phases and graphically we obviously show what new entities we actually added to the meta model. So depending on what phases you really want to focus on, which ones you want to utilize. And one key note here is even though we have actually customized TOGAP with SOA, it's still up to the practitioner to take our extensions and obviously to customize it for their environment as well. Does anyone want to add to that tool? If not, we could move to... I would just say, Chris has said that we really focused on the ADM, as you can tell from the presentation, on the architecture development method. So the major changes are in the meta model itself and in the additional artifacts that we point to in the various pieces. In fact, it might be fair to say that the presentation is the best starting point to understand what the changes are. Perhaps we can move on then to... In fact, there are two questions which are perhaps a little bit related. The first one, which was asked quite a while ago, so I'm finding difficulty to find it, at the beginning, will there be an EPF version of TOGAP that is adapted to SOA? That's from Paul Smudders. And then there's a further question from Pranab Barua, are SOA tool vendors on board to implement the meta model? And from Peter Bradbury, has the work group been working with any tool vendors, and if so, have any export adoption within these tools? So perhaps we could ask the panelists generally to comment on how the practical guide might translate into a tooling environment, and if there are any specific tools or connections to tools that they know of? This is Smuddersky. I'm the co-chair of the SOA Working Group. As Ed mentioned earlier, there weren't many changes that were made to the TOGAP meta model. So it's basically two or three new entities, and they would be reasonably easy to add, and there's actually projects ongoing within the Open Group. There will be changes to TOGAP in itself in the future, and information architecture will be added to TOGAP as a full discipline and maybe as a full phase, it's unclear what will happen yet. But the main change is around information. The need for having a clear understanding of the information and information structure that's going to be used by all SOA services. But when it comes to meta model and tooling, it's also a project, a TOGAP meta model project with the tool vendors where the Open Group has created a set of restrictions to put on tool vendors, so they should be able to put a stamp on their tools to be TOGAP certified. Dave's review is probably no more about that than I do. Yes, the tool certification standard is currently undergoing what's called Company Review Inside Finger, and it is a broad view of compliance for certification for a tool to be used with TOGAP. One of the proposed conformance requirements is the ability to extend the meta model, which would be the ability to add four or five new entities. Okay, so no specific tools there, but a general mechanism by which tool vendors could plug into this by extending the meta model and could achieve certification of their products, not SOA, but in a TOGAP context. And of course this meta model and the TOGAP meta model and the meta model extensions we put in, as he was saying before, it's all adaptable, and this is one suggestion, one best practice that we suggest, but it needs to be adapted to the needs of every individual organization. Okay, unless anyone else wants to leap in, perhaps we could move to... There's one question I think we can deal with fairly quickly. Is SAO a typo of SOA, or is it a relevant distinct abstract? I'm not quite sure where you've seen this, but I'm pretty sure it must be a typo of SOA. So hopefully that can clarify that. Okay, so there's a question from Hussein Chinoy here. Is there a generic vendor component, ESB, registry, repository, runtime proxy, mapping to TOGAP phases or meta model components? I don't know who would like to take that, but it's an interesting question. There's no mapping of vendor components to phases or the meta models, but what you will see on the slide that's above here, and it's pretty hard to read, on the right-hand side, one of the projects that we relate to is the SOA reference architecture. And what that reference architecture does is define the capabilities that are required and map the relevant components to that. So what work that we've done here is actually referred to that, and that when we say stuff like platform service and logical technical components, that's actually going to be realized through and be an instantiation of what your reference architecture looks like. And in the preliminary phase, we actually said one of the inputs was to bring your own SOA reference architecture. The SOA reference architecture don't go down to any vendor components right now. In the future, the SOA reference architecture is just being made ready for company review and will be released reasonably soon. And I imagine that the next step could be that different vendors would map to the SOA reference architecture and show how they fulfill it. Okay. Any further comments on that question? If you look at mapping to different phases, the color schemes on the slide we can look at is really mapped to phases. So in the meta-model object, the yellow ones are business. The greenish, light greenish ones are information application ones. The red ones are data. The blue ones are phase D ones. And the black ones or the dark ones are phase E. And the green ones surrounding it are the different projects that are how the input, how the output from the photograph work, the architecture work you would be doing would be input to different types of SOA projects that are ongoing within the open group. Okay. Perhaps another thing to mention regarding specific components. In fact, it was mentioned briefly earlier. We are in the final stages of preparing an SOA reference architecture, and that will provide another context in which people can place specific SOA components and perhaps can assist people with identifying how those components might map into their architecture. There are another two questions here which perhaps we can consider together because there is a linkage between them. Does the practical guide include an example of implementing toga.soa in a fictitious company rather than just description of what should be implemented? That's from Wilson too. And from Stephen King, do you have any practical examples or case studies of this in use? So it's a question of examples showing the use of the guide either fictitious examples or real ones if perhaps the panel can comment on that. Hey Will, you've been very quiet up to now. Do you have any thoughts on the practical guide in actual use? I see A Will's on the web, but not on the phone, so that's probably why he's been quiet. I'm not quite sure what the problem is there. We started in the beginning or in the middle of the development of the practical guide. We were discussing an example, but to do a good example, it takes a really huge effort. And to do a small example usually doesn't give you anything. So the problem is to find the appropriate level of example that really shows all the benefits of this. Plus it doesn't take you the same amount of time that the normal architecture project would demand. But we have it as a possible next step in the practical guide could be to develop an example. And if anyone wants to participate in doing that, please let us know and we'll be happy to let you participate in that work. And that's a leading to another question about how we can get involved, but perhaps we can move on. There's been a flood of questions coming in and I don't think that we are going to be able to deal with them all. A question here from Pranab Barua. Is there any effort in Toga to rationalize the SOA approach with ITIL V3? And I think the short answer to that is no unless any of the panelists wants to leap in and contradict me on that. In the governance project, we looked at ITIL V3 and the relationships to SOA governance. So that was an approach we looked at. We also looked at COVID as a reference when we thought of the work. We did some active work on both ITIL and COVID, but they didn't actually make their way into the final output. It was just something we did as understanding the context. There is also, Chris, the Open Group have done the effort to actually map Toga to ITIL V3 and that white paper is available. Hopefully that will be without our SOA extension. And is that a published paper? Yes, it is. On the question on the information entities that I can see from Raymond Brookman, it's based on the information architecture project ongoing that product produced in the white paper and that white paper will hopefully soon be released and used that the way the architecture form usually works produced white papers and then at a certain time we take those white papers and move them into Toga as appropriate. But of course information entities will be extremely useful in non-SOA projects as well. Yes, indeed. Has anyone produced, I think perhaps this would better be the final one of these questions and then we'll go back to how people can get involved. Hi Chris, can you hear me please? Yes. Yeah, I had a phone problem trying to get through. I just have to dial again. Okay, well perhaps you'd like to introduce yourself, I will and perhaps you could maybe comment on the question has anyone produced any samples using the updated metamodel and can these be shared? Or perhaps also on a previous question which was about practical examples of the use of the practical guide. Okay. Yeah, my name is Awol Diko. I'm a co-chair of this project and also a co-chair of SOA working group. Yeah, example-wise, we have a tutorial that we use as a fixage company which explains the practical guide but for real use case study we have an end-up piece in this project because our focus was really how one can position SOA within the higher inter-product picture context, linking various elements that are involved in this whole of inter-product picture like governance, reference architectures, the producing of the capabilities and so on. So from the start, where is the SOA feed from a variety of states of iteration or phases? So the practical guide really what's recommending or suggesting as earlier presenter was talking about is positioning SOA at high level, starting from high level and leading down to the vitalization to the infrastructure. We have in this project the scope of not to map to individual technology elementists like I see some questions like SOAP, RSPC, REST and those kind of questions. It's not to map to this detailed technology aspect rather what is the TORGAP and what's missing from TORGAP and what I think is we can enhance in TORGAP to make use for TORGAP for SOA projectors. So looking into guide, maybe the next detail may be mapping to the actual projectors. There was also a question around vendors. Is there any real vendor mapping to the metamodals or practical guide recommendations? Again, the practical guide is trying to link many things which will involve big tool of course many tools including government infrastructure various inter-product nature tools. So it's absolutely enterprise really to mix best of breed or to solve this problem. The practical guide is not recommending any of those any specific tool from vendors. I think a while without a question. Thanks for providing those answers. In fact, we're now coming I think to the end of our advertised time for this webinar. So I would like to thank again our panelists Abel Dico of the Bank of Montreal, Steve Bennett of Oracle, Dave Hornford of Conexium Matt Sceniaval of Capgemini and Ed Harrington who gave the presentation from the start of Architecting the Enterprise. In terms of how people can get involved in these activities if you are a member of the open group or if your company is a member of the open group then you can join the SOA workgroup any member of the open group is able to do that. If you're not yet a member of the open group we don't at this point have a mechanism for involving non-members in our SOA work. We do for the cloud workgroup. You can join what we call the cloudsters list but we are looking at putting in place means by which non-members can contribute to the ongoing evolution of our SOA standards and guides and we can be in touch with people who we have records of if you wish us to do so as those plans develop. Finally we do have in terms of getting in touch with people we do have a number of questions unanswered. Is there a way Simon by which if we have answers to these questions we can make them known to the people on this call? Yes Chris we maintain a record of all the questions asked so what we can do I can send those to you and you can answer those offline Chris. Okay so we will do that and you will be writing to everybody after the call with details of where to find the materials. Correct everyone will get an email with a link where they can access the event recording. That will be tomorrow. Okay so that's excellent and I'd like to thank as well as our panelists I'd like to thank very much everyone who participated in this webinar particularly those who asked questions and contributed to the flow of discussion so thank you very much everybody and I hope you enjoyed the webinar. Thank you. Thanks Chris.