 Well, welcome everyone to this webinar from the open group today, which I'm pleased to say is being led by Dr. Ali Asanjani from IBM, and Dinik Alkumar from AP Unters. Today, as we're looking at SOA, that's it from me, so perhaps I can hand over to you, Nick, to start the presentation. Thank you. I will start off with a quick overview of what we expect to cover and what you will learn from this presentation. This presentation is an overview of the open group SOA reference architecture, and it kind of will also look at the role of SOA in the cloud. It also covers how we leverage the SOA RA to create and evolve several service-oriented architectures, which includes road mapping using the SOA RA, which is now a formal open group standard and is in the process of becoming one across the ISO domain too. And the OSIM, which is the service-oriented maturity model, which is another SOA standard from the open group. We'll also go through a series of steps, or we'll provide an overview of a sequence of steps which we can use to realize and create solution architectures and briefly look at success factors. We will look at examples in the future. So Ali, do you want to take this slide? Sure. Greetings, everyone. Thanks, Nikhil. So in the context of building solutions, and in the context of trying to make solutions meet business requirements and meet business needs, which has been the holy grail of what we as architects and software engineers have been trying to achieve, we are taking SOA service-oriented architecture as a base set of capabilities or services that collectively, in terms of the entire service portfolio, help fulfill the business needs and the fact that we need to share a common SOA platform based on which we can build our solution. Based on that kind of a basis, we provide an SOA that allows us to bind business and IT together in a fabric of common terminology and common understanding by having a linkage between the IT domain and business architecture through enterprise architecture via SOA. These capabilities generally help us address business agility by having a robust set of services and capabilities and map business and IT together. We utilize, so that has been the general message, but until the SOA referenced architecture, the process of actually building out the solution has been pretty elusive and pretty much a cottage industry. People are building very good SOA solutions, but they're doing pretty much one-off. They are not consistent necessarily across vendors or consistent across clients or vendor. If you want to have a product perspective that are multiple products there, how do you combine all these perspectives together and form a consistent foundation? The SOA referenced architecture provides you with a set of capabilities and architectural building blocks that will help define that realization, that common platform on which you can fulfill the business needs. It allows us to link with not only SOA, but the options of SOA such as the services that a cloud provides and the adoption of cloud in an evolutionary and transformational fashion by saving it into a roadmap. We utilize another one of the Open Group Standards, which is the OSIM model, the Open Group Service Integration Maturity Model, to help move the organization forward in terms of its adoption and evolution. So Nikhil, if we could advance, please, and maybe you want to take the next one. Sure. So watch in it for me. Organizations are adopting or evolving SOA and cloud solutions. As enterprise architects or IT thought leaders, we face this all the time. And what the SOA RA does is it provides a vendor-independent approach so that we don't get mired in religious wars about product or protocols, you know, mainframe versus distributed or .NET versus J2E, et cetera. It provides a holistic common point of reference for all the stakeholders. And, you know, as Ali mentioned, different stakeholders across the IT realization cycle, so to speak, can see the same terminology, the same verbiage, and understand the same things. It provides a framework for conformance and solution architecture derivation. We talked about capabilities, and we'll talk a little more about capabilities and architectural building blocks in the next few minutes. And it is scalable. So you can take this from the level of an ecosystem and bring it down to the level of individual solution architectures. And that's something which trying to build from scratch again and again as enterprise architects, we do that all the time. Well, that takes a lot of time, and it's not very productive, but here we've spent a lot of time across multiple organizations and come out with a standard which all of us can agree on and move forward with. And that's a big piece of leverage for enterprise architects to leverage in their internal organizations. Product vendors have a perspective for it too because this gives them a framework against which they can build solutions they can leverage for compliance and differentiation. System integrators use it to carry out implementations and develop cloud and SOA architectures. And standards bodies such as the HDNG, for example, are already leveraging it to define their future state or rather their future state solution architectures across our industry architectures across the different lines of business. In particular, the SOA RA provides the ability to adapt, evolve, and transform SOA and cloud solutions. It is a vehicle for agility and reduces the cost of RA definition, which is something you'll find is the biggest kind of... I would almost put it as the impedance for adoption of enterprise architectures and solution architectures. So if you look at it, what are the key steps involved in using it? You need to assess an existing architecture. Think about it almost as the use case there. You have a checklist of layers, capabilities, architectural building blocks to validate against, and that kind of answers the question, how can I assess whether I have the right things in place? You can use it to design a new or extend an existing architecture, and that helps us answer the question of what are the things I need to build design to meet my requirements? Finally, as architects, we often face a question of how do we incorporate the cloud? And the RA plays a major role in providing the building blocks around which cloud solutions can be architected. As you can see in the link down there, there's the link to the actual physical SOA RA standard, which you can all download whenever you have time, if you have the interest. So Ali, do you want to take the next slide? Certainly, thanks. So this iconic representation of the layered view of the SOA reference architecture is important because it gives us a high level perspective around which we can build all the details. So this is a representation, an iconic representation of the SOA reference architecture. The reason I'm characterizing it as such is that all pictorial representations have their benefits. As you try to explain it to different people, you'll find that there's a lot of benefits to this view. There may be limitations as well as all representations have. Here we have five main layers in the SOA reference architecture, starting from your runtime systems, your operational systems that are running in your host operating environment. And if you take a snapshot of that in time and expand that out, you get these other layers, essentially. You get a bunch of components, service components, that are realizing they could be .NET components, EJB components, so on and so forth, that potentially realize, at least some of them realize, services that are then exposed at the services layer. And the services layer is sort of a mediation ground between the provider and the consumer. You can look at the provider view from the bottom up, from the operational system, service components and services up, and the consumer view from the consumer business process and services layer downwards. And their meeting ground is at the services layer. Note that these horizontal layers are cross-cutting with four vertical layers, if you will. And those vertical layers are superimposed upon each other. They're stacked, if you will. You see integration above quality of service, above information, above governance. And all of the horizontal layers cross-cut all of those four layers. So I want you to keep that in mind when you're using the RA, so there's an intersection between services, integration, quality of service, information, and governance, and so on for the other layers. Now if we combine services, orchestrate them and combine them in some shape or form, in terms of orchestration or choreography, into business processes, into more coarse-grained services, you get the business process layer, which can string together and wire together these services. And they can be accessed by a consumer layer. Now the consumer layer can go directly to the services, or they can go to the business process layer. And of course the services are realized by a combination of service components and their corresponding operational systems, wherein the application servers, the databases, legacy systems are all running. The integration layer provides a layer of indirection and mediation between everything. It could be at a very, very primitive level, let's say level four of OSAM, it could be point-to-point. As we mature from four towards five, we can get more and more into enterprise service bus kind of scenario, and that would be the home for where the enterprise service bus resides in the integration layer. Whatever mechanism you utilize to integrate services together would be in that domain. The quality of service layer is then responsible for maintaining, ensuring, monitoring, and managing the quality of service that the service provides. And the information layer provides the backdrop for all the aspects of data and business intelligence, schemas, et cetera that are necessary for the realization of services all the way down to the databases. And the governance layer itself would be the home, for example, for the registry and repository, or registries and repositories that are needed to realize services. Collectively, these nine layers form the logical boundaries and logical partitions and groupings around which you'll see we're going to provide further levels of granularity. So if we may go to the next slide, please. What I just described is summarized in this particular slide for your future reference. If I would interject. Here's a point I want to, I think we want to make clear. Is there's a separation between runtime versus physical or other logical versus physical? And if we were to go back to this slide, you would see there are eight of these layers that reflect logical components while the operational systems layer is kind of the home where all the physical components run in real time. So where all the logical elements are instantiated. Ali, do you want to continue on this slide or should we move to the next one? No, that's a really good point. The importance of this aspect of the logical versus physical is that we often develop application architectures based on a logical view. We ultimately have to map them and realize them on a texture so that distinction is an important one. So the relationship between capabilities, architectural building blocks and layers. Nikhil, do you want to take this, please? Sure. So we can think about layers are logical groupings of ABBs that's architectural building blocks and capabilities. Think about capabilities as what your SOA needs to support, the requirements of the SOA. So if you have business capabilities defined, which say that, you know, for example, we need to be able to route a message from a smart grid application at a particular speed in case a transformer goes down, then that helps us determine what are the capabilities that the SOA needs to support. And from that, we can pick the corresponding architectural building blocks. So there's a relationship between these architectural building blocks and capabilities. And if we group these ABBs and capabilities together, then we end up with the layers of the SOA RA. And so that's an important mechanism for us to decompose and map business needs and business drivers to actual capabilities that you need in realizing solution and application architectures. Do you have any other comments you want to add to this? Yeah, no, that's fine. Thank you. Do you want to take the slide, Ali? I'll take the next one. Right. So the cloud architectures are extensions of SOAs. Now that's an important thing, even if you were to look at the NIST model, you would see that one of the inherent attributes of a cloud are that it is service-based. And we actually have a technical reference model on the next slide, which illustrates what is a typical perspective for the cloud and how cloud RA standards can be based and how cloud interactions, which are driven off of a consumer provider model, can be used and derived from the SOA RA and how they can be mapped to the SOA RA. And that helps us to kind of refine and leverage this extensively. And in fact, the upcoming cloud RA standard is going to be based on and is significantly derived from the SOA RA. If you were to look, Ali, I'll go through this slide to kind of... I kind of authored this long ago. So anyway, the basic point over here is that if you were to look at a cloud interaction, there's a consumer and a provider, and there's a regulator. And this is a very simple perspective, and the reason I'm bringing it in is that if you look at a service, this is really what's there in a service too. And that's the compelling reason why when we look at cloud solutions, especially as enterprise architects, you can start realizing that you've got a daisy chain, these services together, and there's this direct correlation. And what becomes more and more important in cloud solutions is the role of the regulator, even from a perspective of if you're a provider or a consumer, because you need your data and your SLA to be monitored and auditable. Do you want to talk with the Matrix or do you want me to go ahead with the Matrix, Ali? Yeah, go ahead with the Matrix and I'll chime in. Sure. So if you were to look at the capabilities of the cloud or the characteristics, as we've called it, about the cloud, they can be mapped against the deployment models which traditionally exist in the context of the cloud and the service models which have evolved in the context of the cloud. So you can actually determine a particular cell where does my particular problem fall and what are the capabilities I need based on a combination of these two attribute sets, whether it's a private cloud, for example, and whether it's a business process as a service. And if you look at that combination, you can actually derive what are the core capabilities which are going to be of import to you. And using that, you can now determine what layers and what components of the SOARA factor in over here. And now you can refine that further as you determine what non-functional requirements are there. And we'll look at that in the SOARA metamodel in a few minutes. And you can take the SOARA metamodel to further refine and determine your individual solution architecture. This is a brief look at some of these characteristics from the three different perspectives we had consumer, provider, and regulator. I'm going to actually move forward. We can look at these later. Ali and I are also planning to hold a future webinar to conduct a workshop to actually walk through certain scenarios and actually show a particular pair of examples which we can actually execute against. And so that's when we will really go into details on this particular slide in the future. Ali, do you want to take this? So in terms of the SOARA usage content, usage context is going to be important. Sorry, Ali, it's just Simon here. Ali, can you try and speak up a little bit? Your volume is dropping a bit low. Is it better now? That's better, thank you. Certainly. So in order to utilize the SOARA, we need to realize that as a logical solution architecture or an enterprise architecture standard, we need to instantiate it. In other words, we need to create a concrete, either solution architecture or some kind of an intermediary industry architecture that will ultimately be instantiated with concrete elements in it. So to that point, we have this notion of business capabilities that we need to align with and that are actionable. And then the SOA capabilities that map to the reference architecture and are quantifiable. And then ultimately the architectural building blocks, which the open group provides a normative and prescriptive set of keys, and then map them to the solution architecture constraints, ultimately, in terms of solution building blocks. So let's move to the next slide, please. Thank you. So in order to do this, in order to instantiate this, let's take a look at what sits behind the SOARA, the metamodel or the conceptual model behind the SOARA. This is basically showing that we have a set of layers, a number of layers, that collectively contain a number of architectural building blocks. And those architectural building blocks can be composite, and they interact with one another. So there are interactions between these architectural building blocks. If you look at it from a slightly different perspective, there are a set of capabilities that are then realized and correspond to these architectural building blocks. You can think of the capabilities as a set of requirements and the architectural building block as a means of realizing those requirements. These layers, essentially, are going to have a number of architectural building blocks slash capabilities associated with them. But these building blocks, these architectural building blocks, will often have non-functional requirements associated with them as well. And these non-functional requirements will partake in your designation of certain KPI's, key performance indicators that collectively will influence your architectural decisions. These architectural decisions may be about architectural decisions about layers, about architectural building blocks, and so on. So they may be at various levels of granularity. But ultimately, there are going to be enabling technologies for these layers that will influence and impact your architectural decisions. The enabling technologies realize these architectural building blocks. And of course, to concoct your solution, you need to have a set of options for these architectural building blocks. Once you select an option through these architectural decisions, you will then result in an instantiation of those architectural building blocks. So looking at it very simplistically, each of the layers in your SOARA would contain a number of architectural building blocks and a number of capabilities would be associated with those layers. So if you're trying to assess, then you would go through and assess based on your capabilities. Imagine a spreadsheet with all the architectural building blocks listed there and the capabilities for each layer. And you would then conduct your architectural assessments against those. Alternatively, in the other use case that we just described, you're trying to design an SOARA. You would then go through and identify which ones of those architectural building blocks are needed. Based on the NFRs and KPIs and the requirements that you have, the capabilities that you need to actually function along. Yes, please continue with the next. Sorry, that was just my finger. No, no, that's perfect. Good idea. So in order to instantiate the SOARA, we look at some key performance indicators and non-functional requirements and business capabilities that collectively form your requirements. They help constrain the reference architecture and they help us look at all the options and arrive at the architectural decisions that are a selection of the options based on the constraints. This helps us determine the required capabilities, architectural building blocks, and solution building blocks that we need for our solution architecture. So moving along. Right, and so I'll just interject for a second. So if you look at this, this is a very important slide from my perspective and I think from our perspective in general. That is whenever we are dealing, let us say, with a legacy migration scenario and you have a number of different applications and you're trying to rationalize things, that's when the ability to determine what is the actual solution using this constraint-based model is very powerful. This series of steps, so to speak, that we have shown in this slide, that is very simple, very elegant, which we can just repetitively apply. And the availability of the capabilities and the architectural building blocks and their definitions helps architects as well as solution implementers quickly come to solutions rather than indulge in a lot of... relatively leverage the time better would be the way I would coach it. Some common use cases in this scenario are establishing enterprise SOAs, designing solution architectures, assessing and existing solution architecture, determining and selecting product platforms, and building an industry reference architecture. We'll walk through a couple of these use cases to kind of give an idea of how we recommend to get a result using the SOA RA. And I'm going to hand it over now. Ali, do you want to take the slide? Yeah, that's fine. First use case among them are the establishment of an enterprise SOA. This requires a portfolio of your capabilities. What are the business capabilities that are required? What are the corresponding technical capabilities that will be used to realize those business capabilities? So now the question would be what part of the SOA RA do I need to accomplish this? You would then map these capabilities that are required to the SOA RA capabilities that you have as a list. Through your layers you have the capabilities. And then based on the different context in which you are functioning the KPIs, the NFRs, and the constraints of your project, layer by layer you go through and identify the architectural building blocks. You check off the architectural building blocks you require and capture the specific constraints that are related to those architectural building blocks so that you can make product mapping and realization decisions for multiple vendors as you move forward. Nikhil, would you like to add to that? I think you did that fine. I was going to have you take this one too. Okay. So in the design of solution architectures as well, we now get more granular. And for example, in the case of providing mobile self-service, you have a very specific problem domain. You want to get a little bit more granular. What are the different options you have? You may have various backend and J2E, for example, provider modules. You identify the key performance indicators and non-functional requirements. For example, a five second response time with multi-factor authentication. And then work on the architectural decisions that are related to it. For example, the selection of integration adapters, the routing and mediation mechanisms you want to use. And so you would utilize the SOA RA to map them to the solution capabilities you have. Capture your constraints against those building blocks. And then you can perform the mapping to the solution building blocks which realize your solution architecture, i.e. the product mappings and capabilities that exist within actual products and solutions. So we've gone a step down from the enterprise capabilities into solution architectures with this use case. And just to add to that, we could go a step up also. If you were talking about ecosystems or industry reference architectures, you could really leverage the same model. Only your business capabilities would be dealing with an industry level or ecosystem like quality governmental level or organizational level characteristics. Right. So the third use case is assessment of a solution or SOA RA in which, again, we keep articulating that you need to know the capabilities and constraints. So it's important to understand what are your business capabilities when you're assessing a solution. We always say we need to know our requirements, but capability mapping is an important aspect of applying solution architectures and reference architectures. And make sure you have a clear understanding of your technical capabilities. Map them to those SOA RA capabilities. That's your rubric. That's what you're measuring things against. That's where you're taking your decisions. Now you know your layers. Can you see any discrepancies? Do you see things missing? Do you see mappings to a roadmap? And we'll take a look at a couple of slides to see what happens. But when you're looking at it now for a particular solution and when you're assessing it, you're really saying, do I have the right business capabilities addressed here? Are they mapping to the RA? And because the RA provides a whole and complete collection of capabilities, architectural building blocks, and relationships between them to a certain extent, please, we can help determine what should be there if it's missing. And so your gapping process becomes much simpler. Ali, do you have any comment on the assessment, or are we okay? So I think at this point, if you agree, let's briefly open the floor for some questions around the scenarios that we just described and see if it jives with what, you know, our colleagues here are seeing. You know, points of clarity you would like to engage in and things you'd like us to elaborate on if that's possible. So we have Ajay. Which other? If you can provide any guidelines on assessing or identifying business capabilities. Clients more times than not can't articulate them. So in terms of the SOA reference architecture itself, we're not providing specific guidance. The how-to from a method perspective is not captured in the SOA RA, per se. That would be more in terms of the open group, the TOGAP ADM architecture development method, and other methods such as the STOMA method, service-oriented modeling in architecture, or other methods that have come after it, which essentially provide the guidelines on how we identify business capabilities and services. We don't necessarily provide guidelines in terms of the SOA RA, per se. So to add to that, Ajay, basically the way we are doing this is in the context of the SOA, the capabilities are defined in the SOA RA. In the context of business capabilities from the perspective of the standards coming out from the open group, there is a project called SOA for Business Technology, which will help map the business capabilities to the SOA RA. Its goal is less, I would say, to provide determinations of, you know, as Ali articulated, there are different methodologies and different organizations have different criteria to determine or litmus tests, if you want to call it, to determine which business capabilities are of importance to them. What the SOA for Business Technology will do is it will provide an articulation of what are business capabilities and how they can be leveraged to connect into the SOA RA. And the SOA RA really is the one place you're looking for, for all the technical capabilities you need to support those business capabilities. That's great. We also have some questions in the QA section, Ali and Nikhil. Do you want me to just go through those? Sure. Okay, well, we've got quite a number here, so I'll just start and work my way through them. I've got a question here from Mike. He's asking, does each organization have to maintain its own repositories for services, or is it accepted that service access can cross enterprise boundaries, worldwide access, et cetera? Nikhil, I'll take that, and then if you would like to... Sure. So generally speaking, Mike, it would be ideal if we could have that level of trust. I think there are no technical impediments to it. I think there are more organizational or security or perceived impediments to that kind of an ecosystem level integration or repository-based kind of perspective of where do you store my services? It tends to be that organizations want to keep their services inside their own registry and repository and then have circles of trust. So they would have, just as you would imagine, for a certain business line, they would only expose... If you start with a specific business line within an organization, they would have access to everything as they start going enterprise-wide. Maybe they restrict the access, not necessarily for security purposes but because of relevance, for example. And then as they go to their business partners, they restrict access yet again. And then as they move into their customers, further restriction of access, and then the ecosystem would be the least number of services exposed. It is perceivable that you could access these repositories between companies and have repositories that provide a brokerage kind of service between enterprises in the ecosystem. And that's a direction that is a slow direction but it's moving in that direction. But I personally have seen the tendency of organizations to want to house their services in their own organizations and have those levels of trust. That's sort of just sort of an experience. Nikhil, you want to add to that? Sure, I have a few points there. So one, I think, as Ali articulated, there are ecosystems developing would be the right way to couch it because of the growing adoption of the cloud. So there are quasi-governmental or... I would almost put it like organizational supply chain or organizational chain scenarios where different organizations communicate and commit and develop trust relationships. So that federation has started and as Ali articulated, there is an evolving acceptance of the possibility of the concept of a cloud broker, really. There is another aspect to this and that is trust where there's a consumer viewpoint. Trust tends to be a combination of context as well as credentials provided. And so the circle of trust model gets extended to kind of address the credentials that different consumers, if you provide more credentials, for example, your bank allows you to see different data sets. This applies to services in the context of services require different levels of governance and different levels of quality of service constraints as they evolve from one circle of trust to the other. So if you have a service which is exposed out of the context of the enterprise, obviously there are different SLA constraints in terms of response and there are very different SLA constraints in terms of security. So that would be my additional comment to that question. A quick question, Simon. Are these questions all being captured and could you put them into the chat or something so that we could all see them? Yes, I can copy them over. We have some other questions here. Let me just bring two together. We've got a question here about ABB, one from Consola, one from Mike. So let me read them both out and see if we can have them together. So the first question is, because they're asking, is ABB based in one technology or is it generic? And the second question which relates to this is could you draw a distinction between an ABB and an SBB in terms of specific capabilities, say our CRM capability or assistance management and monitoring capability in an enterprise? And it says that doesn't SBB have to include specific products? Can you handle those two guys? Sure. Yeah, yeah. So I'll take the first part of the question if I may. Sure. And then you handle the ABB to SBB mapping. Sure. There we go. So tag team, go ahead. If I remember the question correctly, the architectural building blocks are product and platform agnostic. They are, for example, you may have in the integration layer, you may have mediation, routing, transformation capabilities that have associated with them, architectural building blocks, as components, if you will, that provide those capabilities for you. So they would be generally agnostic to product. But when you do select a product based on your constraints and functional and non-functional requirements that you'd like to meet and general capabilities that the product would need to have, you would then say, okay, I'm going to check off. Yes, I need routing. Yes, I need mediation. I need really fast transformation capabilities. So then you would say, aha, if I wanted to go to some vendor, maybe I need not a regular ESB, but maybe an appliance because I have fast XML translation, transcoding transformation capabilities I need. And so that would help you guide towards the solution mapping, the instantiation towards the actual solution building block from the architectural building block, which is a good segue to you, Nikhil. Right, so very simply, the solution building block is that stage where we have gone to defining a particular solution architecture. So for example, let us say we picked as an ABB mediation. Mediation has a certain set of capabilities. We went through our process and we refined and determined that our mediation component has to be highly available, available, and we have an architectural constraint that it has to work with, say, .NET, J2E, and some other environments. Based on those constraints, we can basically determine and make a particular solution selection. It may be because of the maturity level of the organization that this is going to be a collection of point-to-point services without the mediation, which normally you would like to see. At that point, you can then determine, okay, we're going to use HTTP as a platform. And I'm trying to be facetious because these are very simple selections, but here you're coming out with the determination of a solution-building block. Now you may have constraints which help you determine the monitoring and security requirements. And that may help you further refine your solution-building block to say, look, we need to have SOPES transport. We need to have a particular FALC model. We need a particular security non-repudiation model and we need to have a certain speed of transport. Excuse me, speed of transport. These are the different elements which will now start determining what your solution is. And the solution-building block is actually that component which you can actually start utilizing in the operational runtime environment, in the operational systems layer. So we have moved from essentially a logical component, which is the ABB, to a specific component which is the solution-building block. And just out of, as an FYI, the standard in particular addresses this question right up front in an FAQ format or an FAQ fashion early in the document so that everybody gets a quick understanding of the different aspects of the SOA array. Thank you for that. Another question to follow. This is from Mike. How does an enterprise or enterprise architect or application architect know what services or service components are available for building applications within his or her enterprise? How is this access administered worldwide? Ali, you want to grab it or you want me to grab it? Do you read the beginning part of the question again? I apologize, I didn't quite get to the beginning. Yes, of course I can. How does an enterprise or enterprise architect or application architect know what services or service components are available for building applications within his or her enterprise? And he follows on how is this access administered worldwide? Okay, great. Great, thank you. Yeah, I'll have to take that. So back to the question around registries and repositories. The visibility in terms of, so first of all you've got to define and identify those services, which goes back to the very earlier question. So once you've identified them and they're sitting in a repository and registry and they've been validated over governance, that these are indeed the ones that should be there for the enterprise or for different circles of trust or for different circles of applicability. They're sitting there now to your point, how do we access them? Well, the mechanism of access would be, they would have to be sitting in circles of trust and access within a registry and repository. I mean, they could be on a wiki. I have clients who are at various levels of maturity. They go anywhere from a spreadsheet to a wiki. So those are very primitive forms and you can get away with a few initial services and you can get away with the early days of adoption and putting your toes in the water and understanding what the landscape looks like. But as you get more serious, obviously, in the context that you were asking the question, which is an enterprise architect's perspective, it definitely needs to be a registry and repository that you have access to worldwide. If you have a global enterprise, the access of that global enterprise in a federated set of registries and repositories is going to be paramount to your gaining visibility and access so that you can actually leverage services for reuse and leverage them for orchestration, potentially in a BPM. So I'll pause there and see if that's sort of in the direction of the question that you were or the answer that you were looking for. If you can kindly give us feedback via chat or voice, I'd be appreciative. Thank you, Ali and Nikhil. I've actually come and pasted a question from the QA section into the chat facility. The question writes at the end of the list of the chat. I've done this because it's a reasonably complex question and I'm going to read it, but you may want to read it yourself, chat. So this question is considering the architecture continuum and the solution continuum in a specific enterprise. Is there a continuing divergence between the organization and the outside world due to the channeling of the architecture through the, and he says, FF common, SIS industry or specific? I've said that may make it more sensitive, you can read it, so it is in the chat facility, but is that something you can help with? This is Nikhil. So Simon, I'd like to get a little bit of clarity on what he means by FF common system industry organization specific. If he's referring to the steps that we have shown early on, the answer is I would not think about it as divergence, but more as specification. So to illustrate, we may have at a high level a set of architectural building blocks and capabilities defined in the SOA RA. From an information architecture perspective, for example, we may have a schema specification, say the art schema for retail. We could take that art schema for retail and that's at an industry specific level and it defines a lot of components in a non-verb fashion which we can use across the entire enterprise. Now if we take that down to the next level, which is on a specific organizational level, that's where you take it a little further and say in my context as an organization, what elements of the schema are relevant? And so, for example, we may have a subset of the total typeset as well as a subset of the total ontology being leveraged from the schema internally. So it's not necessarily a divergence, I would argue, for a good reusable and effective service set, there may actually be a convergence, only a specialization or a subsetting of. Now, based on your constraints, there may be a divergence, but the process being followed doesn't drive that divergence. It may be specific NFRs or KPIs or capabilities that your individual organization requires, either because of the line of business it's in or because of the manner in which it differentiates itself from other organizations. I don't know, Simon, could you ask the person who submitted the question? Yeah, Mike has kindly provided us a little bit more clarity. So with regards to the end part of that question, he's clarified he's referring to foundation framework, common-sys industry or specific architecture. So I think it refers to us because we talked foundationally, the SOA RA would be the foundational framework. And in that example that I just talked about, the ARTS is a retail industry specification standard body, which has a schema specification, and then I gave an illustrative example about a particular organizational scenario. And from my perspective, again, it doesn't necessarily lead to a divergence. It actually leads to a specialization, if you want to call it that. So generally, the important idea here is that organizations will move through various levels of maturity as they adopt different aspects of SOA. So I remember I was talking to someone who said that we didn't get an SOA because we didn't get an enterprise service bus or we didn't get an SOA because we never got a BPM, a choreography kind of engine, a BPM engine or a BPEL engine. And so really the response to those kinds of expectations is more education along the lines of you started level four and you get some base services going, and then as you move towards the right, you will get various levels of additional maturity going as you adopt different products and capabilities. But from an SOA RA perspective, we need to realize that increasing architectural building blocks and layers will be adopted as we move from layer level four of maturity onwards. And that's very key to understand that you're not going to be adopting SOA, lock, stock and barrel by saying I'm going to adopt everything under the sun by adopting a specific technology and so on. It's important to start from where you have pain points and move towards an increased adoption based on an initial assessment of an OSIM assessment and then a final state assessment of where you want to be and then identify the architectural building blocks via the SOA RA that will get you there to that level, higher level of maturity that you would like to achieve in let's say the application domain or architecture domain. So I'll leave it at that and pass it on back to you, Nikhil. Sure, and what I'm going to do is I'm actually going to go down to the next slide. And this is actually an example of kind of a rather a process view of how you can leverage and define road maps. So you're lying against business drivers. You have determined your technical capabilities and keep in mind that in practice these capabilities and these both technical and business are going to evolve over time. And so in the road map you're going to define these almost as snapshots against particular points in time and align them to the OSIM dimensions to help determine what you would need to be able to do. And then to finish the road map you kind of phase the delivery process and from your governance framework the process governance needs to be able to enable you to rebalance the road map on a regular interval. In particular, if you were applying the SOARA to achieve higher maturity levels you started where you are at the current point in time. You map it to where you are in terms of maturity and then you determine where you are at the next stage based on that meta model that we've talked about. And I'm just going to... One thing we've seen very useful in communicating with stakeholders about SOA and about the RA and about the process of road mapping is to use a day in the life model to provide context to all the stakeholders. Now this is not prescribed in the RA and different organizations and methodologies have different ways of expressing the service life cycle. You can pick and define whichever mechanism you want, map it to your delivery methodology. So if it's crumb or it's waterfall or whatever. But the concepts are important and what does it mean to the stakeholder? What does it mean to the business? What does it mean to developer? What does it mean to an enterprise architect for each of these particular stages? For a service, a day in the life of that service is a very powerful mechanism to communicate what it means in delivering services and service-earned architectures. Ali, do you want to take this slide or do we want to... I think we're actually over. Yeah, just very quickly. Basically, so what you would do is you would realize that each level of maturity will use a different combination of layers and architectural building blocks to realize a given target level of maturity. So you may start at, for example, defining a certain set of simple services, realizing them. You may then add the integration layer with an enterprise service bus. You may then add the business processes and choreograph your services to get to a level five. So it's essential to have that roadmap where you want to be, your target state, and then pick and choose the architectural building blocks from the SOARA that is needed to realize that end state. That's really the main import of what we are communicating with you guys today. I think at this point, we will actually, you know, go closure to this particular presentation. Okay, Ali, if you're happy, if you've got any final comments. I think we're good. Thank you very much, everyone, for participating and listening. Thank you. Take care. Thank you, everyone. With that, I'd like to thank Nick and Ali. I'd like to thank everyone for taking the time to attend this event. And on that note, I think I'll close it. Thank you very much, everyone. Thanks much. Take care. Bye.