 I'm Chris Harding, the Director for Interoperability at the Open Group. And this is the first webinar in our series on SOA in the digital age. The series will cover the use of SOA in modern enterprises that use digital technologies such as cloud, mobile and social computing, big data analytics and the internet of things. And in this first webinar, Developers in SOA, we'll look at how SOA has evolved to meet today's needs. SOA first came to prominence in 2005, although it had been adopted by a few companies even before then. So it's now 10 years old, and 10 years is a long time for a technical approach to last. In its early stages, SOA was a bit like the Wright Brothers Aeroplane, brilliant in concept but somewhat lacking in technical maturity. Our panel is going to discuss how SOA has evolved. John Bell, an independent consultant and chair of the IEEE SOA and Web Services Working Group, and E.G. Nadan, who is a distinguished technologist and lead technologist for global strategic capabilities in enterprise services and brackets applications at HP. I'm going to moderate the discussion and ask the first set of questions. When they've discussed these, the panel will take questions from the audience. So I'd like to start by asking, what were the original key concepts of SOA? This is Nadan. So basically, when going back many years now when service-oriented architecture concepts started, the challenge we had then was integration between multiple applications, multiple technologies, and each one having proprietary interfaces. And one of the key challenges that we wanted to address then was interoperability, and the service-oriented approach, what that brought forth was the ability to interact, the ability to interface between two applications in a standardized manner where the underlying technology and how the content was being delivered and shared really became, you know, it was encapsulated behind the scenes so that the parties who were actually interacting with each other could focus on the business at hand. So those were, you know, that's what comes to mind first, but John, please go ahead. And so many, many years ago I worked on a project for a major manufacturer of agricultural equipment. The problem we had to solve was they had a lot of information that was stored on various collections of mainframes, many computers, and everybody talked a different protocol. But because the web had become so popular, everybody, every one of these systems had an HTTP server. And we were able to write scripts that extracted the data that was needed to be exchanged with other systems, convert it into HTML in a standardized HTML format that we had agreed on, and transmit information between the systems. An early example of web services. Eventually HTML got replaced with XML. All of these things happened, and it created essentially a web service model. If you look at Microsoft technologies, Microsoft had a technology called DDE for Dynamic Data Exchange. And somebody at Microsoft had a great idea, hey, why don't we stub out DDE on the computer so that it makes a network call and sends that information over to another computer, and then it won't know that the DDE service it's calling is actually on a different computer. And it, again, traveled over the network. The beauty of the services-oriented architecture is you think about this from a network-distributed processing model in the beginning. And you can use it for helping with your integration, but you can also use it to create better software architectures. Okay, so thanks, John and Nadin. The idea of interfaces between applications done in a standardized manner which enables people to focus on the business aspects using the web services-based approach or an approach that has evolved from web services looks like the core to SOA. John, can I ask you the next question? Because you were involved not so much from a provider but from a user aspect in some of those early days. You were in the hotel industry, I believe, using SOA in an enterprise architecture and solution architecture context. Can you say something about how SOA worked in practical enterprise and solution architectures? So in the early days, when we recognized it as being a SOA architecture, and so I'm skipping Corba here because many people did not think of Corba as a SOA architecture. But when we recognized it as a SOA architecture, it was really taking XML and leveraging XML over the rest of the resources that were provided with the World Wide Web. That's the HDP protocol and the messaging that goes along with the HDP protocol. I remember the early days of XML or PC. If you look at industries like the hotel industry, because there was a need to integrate with online travel agencies so that they could get the information about your hotels, the availability, the room types, all the information about a hotel to make a reservation. The hotel industry created a standard set of XML documents to exchange to get this kind of information. Those early days, that's what it was all about. It was about creating an XML document and exchanging those XML documents, creating services that essentially gave you the ability to query for a specific XML document and return the XML document. That was very effective, but it had limitations when you wanted to move, you wanted to take these messages and you wanted to handle them in infrastructure that was not HTTP-based, not web-oriented. That's why the initial evolution from technologies like XML or PC and just simple XML over HTTP evolved into things like so. Did you find that doing that helped you to deliver value in business terms to enable the hotels, for example, to give better services to their customers? So imagine a hotel having to integrate with Expedia, with hotels.com, with orbits, with all these many, many travel agencies. If there weren't a standard, it would be a one-off for integration with each one of these travel agencies. Because of the standards, because of the ability to use services and deploy and publish that information in a standardized fashion, the cost for the hotel industry and the cost for the online travel agencies greatly reduced because integration now becomes standard and it's low-cost tools, things that are relatively easy for both sides to implement. And that made a huge difference in the hospitality industry. Great. So that's a great example of delivering business value through ease of integration through a flexible approach to standard interfaces. Can I add on to that question? Well, what I find interesting about that question is initially, during the beginning days, even years of SOA, there was this misconception that just because you are using web services, just because you are going HTTP, you have a service-oriented architecture in place. And it took some time for enterprises to mature and understand that you need an architecture around the services in the first place. So when that realization set in, there was also this perceived conflict between enterprise and service-oriented architecture and overlaps and so on. So the example of the real-life scenario that John spoke to, we started realizing such winning solutions when that level of maturity set in that, yes, enterprises need a service-oriented approach. They need a service-oriented architecture. And that actually facilitated the supply chain integration a great deal because partners realized why bother doing what somebody else is already doing. Instead, they can focus on their core competencies by leveraging what is available through partnerships and through other service providers. So I just wanted to share that on top of the excellent thoughts that John shared, Chris. Okay, thanks, Adam. That's a great addition to John's answer. Can we move then on to the next question? And can I ask you, and perhaps John will want to comment on this afterwards, what impact cloud and other new technologies have had on SOA? Yes, so the advent of cloud is actually, it's almost as if enterprise IT rewound and we came up with a plan. Okay, let's come up with client server first and multi-tier and then services. It's almost seems like it was a plan. Somebody was orchestrating it, not me. But my point is that SOA was the right precedent for setting in the evolution to the cloud. So what happened is because cloud is all about utilization of underutilized resources and also making availability of service providers across the firewalls and the core service-oriented foundation that existed within the enterprise now started getting exposure also at the infrastructure level. Service-oriented architecture was initially focused primarily on applications. But when cloud came in that exposed and expanded the presence of SOA into infrastructure. And the open group actually led the way, I would say, in defining the first technical standard for the service-oriented cloud computing infrastructure, which initially started with a service-oriented infrastructure project. But the timing was such that cloud was also getting the same visibility and it became very clear that there is a very, you know, good intersection between two. So the fundamental impact that cloud has had over SOA is its evolutionary presence in the infrastructure layer in addition to its foundational presence in applications. And the interesting aspect here is the fundamental principles of SOA, even though rooted in applications and definitely having that business perspective, that could be applied in infrastructure which may not have happened as quickly had cloud not come about. So I look at this in that cloud wouldn't exist today if we hadn't already created services-oriented architectures. Cloud needed more than services-oriented architectures, but cloud today is built on services-oriented architecture. If you think about it, from a conceptual standpoint, without taking the network out of the questionnaire, UNIX provides basically five interfaces to any device that connects to. It abstracts devices out with open, closed, read, write, and IO control. So think of those as the five key services. Now, if I can create a web service or a network service that exposes those five key services on a different machine and then use the web protocol to talk to that machine, I've achieved a level of distributed computing. And if I treat that as if it were, say, a disk file system, now all of a sudden I've got a network file system that I can expose as a service. So it's taking that combination of having those standardized interfaces and that inexpensive way of communicating over the net because we did this before services-oriented architectures. The problem was it was expensive and complex. What SOA did was it simplified those interfaces. And that's where I see if we hadn't have done that, if we hadn't have gotten to that point, and then combined with other technologies such as virtualization so that we can dynamically allocate virtual CPUs and virtual storage and those types of things, we wouldn't have cloud. So the cloud is built on web services and it's built on other technologies like the virtualization capabilities. Okay, so it sounds like you agreed not so much the impact that cloud has had on SOA, but more that cloud would not have been possible without SOA and that's why it's been an enabler for cloud. People were saying initially was that it was very expensive to set up an SOA environment because of the infrastructure that you needed to make it work. Would you say that that was true and can I ask you first, John, how have SOA tuning and infrastructure evolved? So SOA started off actually being very cheap. It was essentially you needed to know and understand XML. You needed to know and understand HTTP. You use the same tools that you had available to you, your text editors, those types of things. And it made services very cheap. But as the requirements, the needs for doing integration came along, services became more expensive. SOA added a huge amount of complexity. That complexity came with a lot of value, but it also came with a lot of additional costs and a lot of additional complexity. It's great for solving enterprise kinds of problems, but when they did that, they lost the original value of the simplicity of the early solutions, the XML over HTTP, the XML or PC type solutions. They lost the elegance, the simplicity, and the beauty. And with it, they brought a lot of power, but a lot of complexity and a lot of expense. But things that are hard to do without that. So today what you're seeing is you're seeing that pushback against that cost, against that complexity, and a move towards simplifying. Some of that is an underlying model, the restful model for how you access, you virtually access the data. The underlying information that you need or provide the business services that you're expecting to provide. Some of it is with a representation using JSON instead of XML. JSON is considerably simpler, easier to parse. Some of it is due to the languages and tools that developers are using today. So if you're using a full feature language like a C++, a C-sharp, or a Java, there are very powerful libraries that exist to handle a lot of the complexity for the developer. But if you're using a language like PHP 5, I'd argue JavaScript, Ruby, Python, these languages don't have the depth and richness of libraries supporting them that some of these other environments have. And so there's a preference to go with something that's easier for the developer to implement, easier for the developer to understand. When you look at the developers that are coming out of college today, very few of them have training. And so very few of them have training in the types of technologies that were popular five years ago. Now they're looking at REST and JSON and JavaScript and those types of things. Okay, would you like to add to that, Navan? Sure. So I would talk about the tooling first and the infrastructure next. What's interesting about SOA tooling is, in the beginning stages, more and more vendors started, you know, whether it be IDEs or testing tools. From a development perspective, from an apps development perspective, talk to the vendor, they would say, well, we can generate web services, we can go SOA. And that became kind of the mantra. And I was afraid the next time I walked into a coffee shop, the barista is going to tell me that we are going SOA as well, have gone SOA. But later, after the proliferation of web services and the service-oriented concepts, the realization that we need tools in an entirely unexpected domain, it was a late realization. And I'm talking about web services management. I'm talking about policy enforcement. I'm talking about provisioning. I'm talking about tracking metrics. So these are all things that dawned on enterprises after the fact. It was not exactly a planned approach where the powers that be decided we will have the tools for development and management and operations and governance and so on. That's not how it worked out. The tools actually came first for development. And after the mess was created, to be quite honest, then the realization came, oh, my God, we need tools in this space too. So there was a maturity that we went through at Enterprise IT where initially there was, you know, the vendors caught up for development. And then they played catch up to provision tools and make sure that we can orchestrate the services, manage the services, provision and enforce policies and governance and so on. So in recent years, in the recent past, there has been more of an evolution in that domain compared to decades back when we had the introduction of SOA tools. So that's on the tooling side. As far as infrastructure goes, really this idea that infrastructure can be availed as a service, just like you can access applications, you know, interface is two applications, has actually, you know, that is how SOA has had an impact. And therefore, the fact that application designers, application architects, have to factor in the infrastructure being available as a service when they look at the complete universe of services, keeping a service-oriented approach in mind, is also forcing infrastructure to present itself, you know, make sure that it is available to the application team in that manner. So there is a bidirectional growth of the awareness on the role that services have when the application team consumes the infrastructure provided. Can I ask particularly about the enterprise services bus, ESB, because in the early days, there were a lot of people who actually equated SOA to ESBs. The purists said, no, no, ESB is just a tool, SOA is a philosophy. But there were people who said, well, all you need to do to implement SOA is you go out and buy one of these things. But I get the feeling that we're rather moving away from that with the move towards rest. So are ESBs, are they still relevant? Have they evolved? Have they changed? So I'd like to take that on initially, if you don't mind. I have used ESB in a number of different environments. I have customers now that I'm actually recommending integrate ESBs inside their environments. The way I look at rest is if I'm connecting to the outside world, a restful solution is a really good way to do it. But when I have a lot of different things that are going on internally in the company in order to build that restful model, in order to create those messages that have the information from multiple systems that are needed in order to generate that particular service response, I need to be able to integrate information from multiple different systems. And an ESB with its orchestration capability is a great way of doing that. At the hotel company that I worked at for many years, we had internal message structures that were optimized for the information we needed to move between our systems. We integrated with our outside partners through the web using the Open Travel Alliance and HTNG, which is another set of standards in the hotel industry, which I'm actively involved in. Using those messages in order to do that, rather than writing new services that expose these different messages, we transformed our internal message into these external messages. And in some cases, we get a company like Google which says, hey, we're big enough. We don't care about standards right in the way we want it. And instead of having to create a new service, all we had to do was a new transformation on the existing service. So when the request came in from that channel, that transformation was done specifically for the unique needs of that particular partner. The beauty of this is it dramatically lowered our cost for integration with the many partners that we had to integrate with, even though we didn't take on the problem internally of having to have all of our messages limited to what those standard message formats look like. We didn't have to go with the least common denominator. We could go with the richness of the message that we needed for internal services and then go with the standardization for interfacing with our external partners. These are just a couple of things that the ESB does. But the real killer solution for an ESB is until we had an ESB, all of our integrations were point to point. So when I worked with the website for that hotel company, and I'm sure many people on the phone call have used that website, it had to integrate with our central reservation system, and initially it directly connected to the central reservation system. It had to integrate with the system that managed hotel folios, and initially that was a direct integration. Eventually as we put an ESB in place, that integration no longer went point to point to that system. It went now to our ESB. The ESB figured out how to route the messages, and the beauty of it was when we changed where that message was being serviced from, the client didn't need to know. All the client had to do was hit the same endpoint on the ESB. The ESB would say, oh, I have a new target for this message, and it redirected the target. The other thing is a great pattern for doing enforcement of security. All of the security, we actually used two ESBs, one for the outside world, one for the inside world, and all the security enforcement was done at those ESBs in terms of making sure authentication, credentials, those types of things were provided with the message. So does ESB have a place in today's modern, so architectures? I think yes, but typically the ESB is going to be something that's more for how you're going to integrate your back-end systems to expose the facade, which may be a restful facade to the outside world. Does that make sense? That's a pretty comprehensive answer. Do you want to add to it, Nathan? Yes, not much, but I would say that it's not one-size-fits-all solution. We live in a world where there are varied levels of complexity, the need for control, policy enforcement, governance, it varies. So ESB at the end of the day is more an enabler to enforce the right levels of control and structure, whereas REST offers you the flexibility that today's teams crave for. And if it works in the context of the enterprise for what you want to do, then you have to pick the solution that best meets your needs. And I am a purist, Chris, for the record. I do not believe that just because you have ESB, you can go SOA effectively. You do need that appropriate processes, governance, structure in place to use ESB right. The presence of the ESB does not automatically make the enterprise SOA-compliant, so to speak. So that's all I wanted to add, Chris. Yeah, I'm a purist as well. I'm a purist as well in case I forgot to put that in. Well, Nathan, I think you reinforce the need, whatever you do, for thinking about it and for an architectural approach, whether it's service-oriented or any other kind of architecture, but particularly if it's a service-oriented architecture, the tools, the technology doesn't make the solution. Right. If you have the problem that an ESB solves, ESB is a great solution for that problem. If you don't have those problems, it's a waste of money and time. I'll say that's the code of today so far. Yeah. Okay. That's a pretty good quote. We've looked a bit at the underlying technology and infrastructure. Can we maybe look at how SOA architecture and development practices have evolved? Sure. So, like I said earlier, when the concept of service-oriented architecture set in and when the need for services to be identified in the business context, for business to drive services, and only then we even talk about how those services are to be technologically enabled, there was significant overlap perceived between enterprise architecture and service-oriented architecture. So, the way it has evolved is to work hand-in-hand with enterprise architecture and make sure that the goals are continuing to be realized but keeping the broader enterprise context in mind. And I would also say that there is no one approach that meets all enterprises' needs. Each enterprise must take a look at how SOA best works for itself. So, there is that flexibility. How do you address SOA? How do you adopt SOA in the context of enterprise? Your enterprise, it allows you that flexibility. So, it evolved from the perspective of enterprise architecture and also to a point where enterprises have that flexibility to do what is right for them. It has also crept into or now is more comprehensive, not just for applications. It also applies to the different, you know, the infrastructure layers as well. So, those are two key areas how SOA architecture has evolved. As far as development practices go, the way that applications development teams think has been greatly impacted because of SOA. So, now it is more about and has been for some time to, you know, ensure that whatever we are building that it can actually integrate to the next partner who comes along, to the next application that wants to, you know, interface with us. There is a more proactive urge to be compliant with standards, if not defined standards, and make sure that, you know, interoperability is addressed from the get-go. Rather than, you know, we are proprietary and therefore we are right type of approach from a development standpoint. And just to reiterate a point I made earlier, the application development teams are no longer just looking at, you know, what it takes to build and deploy the application. In fact, there is a significant focus on deployment so that there is, you know, how will we consume the infrastructure services? How can we make sure that we factor in those design considerations early on so that we can avail the services being provisioned in a more effective manner? So those are some of the talks that come to my mind, Chris. Okay. Thanks, Nadi. John, do you have any additions to that? I have a couple of observations. One is when you're looking, so so is the style of architecture. When you're looking at an enterprise architecture, you need to look at what are the services I need that reflect my business services? So if I'm operating a hotel, I need to be able to create, retrieve, update a reservation. I can't delete a reservation. They can be canceled, but they can't be deleted. I need to be able to find available hotels. These are core business functions I'm exposing as services. But when I come to creating a user-facing application, now all of a sudden what I'm presenting to the user in that user interface is a collection of information that may take several services and pieces from the responses to those services in order to build what I'm presenting to the user. So at some point I'm doing some form of orchestration, whether I'm doing it, say, in a mobile device or if I'm doing it in a different layer of middleware, I'm doing something that's specific and unique for the user experience on that application. But if I think of that in terms of what are the services I'm going to offer for that application, now I'm looking at services-oriented architecture at the application level, not at the enterprise level. And that's the thing that I see as a big difference today. Services-oriented architecture really came about as a need to do applications, and then it started being applied as a way of exposing the business needs of the enterprise. Now I see it as being both. But you used potentially different infrastructure, potentially different services. One set of services is typically long-lived because business services typically do not change within industry very quickly. The others are very short-lived reflecting what you need to expose to that end user. Okay. Can we move on and specifically look at microservices? And in fact there are some questions coming in from the audience. Raghavan Velankoyle has asked, what is microservices and its impact to SLA? And Jadie Pichata has asked, how do you think SLA would evolve in future in a federated enterprise where microservices and cloud are given? So can we maybe touch on both of those questions? Are microservices the future of SLA, or are they sort of kind of an interesting side-shoot that might not be part of the main course of SOA? Anyone want to be first on that one? I'll go ahead and volunteer since I've been very vocal in the MSA group on this. So microservices architecture are a subset of a full SOA architecture. So it's a SOA architecture with certain design constraints on it. So I don't see MSA in SOA architecture as being different things other than one's a subset of the other. One of the things with MSA is that MSA is part of what I was referring to earlier in the discussion when I talked about that need for simplification. When you see a lot of MSAs, they're implemented specifically to expose APIs. And they represent that need to do a simplified implementation both for deployment and for operationals for a number of reasons. And so if I'm putting in a new system, whether it's custom built or off the shelf, and it's got a MSA implementation to expose an API for that system, while the API for that system would typically not be exposed through an ESB in this case, I might use it through an ESB in order to create more complex services by combining the MSA implemented services. When you look at a cloud environment where you're dynamically allocating resources, it becomes very important to be able to do these types of things. So that's the way I look at MSA. As a part of SOA. Nathan, is there something you'd like to expand on? I would say very quickly I would say that when SOA originally started it was okay, it is an application and then we need to interface and expose services, consume services and so on. Microservices has introduced the interesting concept of even within the application is composed of many microservices. So even the application is bound because of a combination of multiple microservices. So it's more the component-based approach where you're bringing together multiple components to form the application in the first place. So that's all I would add, Chris. Yeah, so the other discussion that came out was that when you look at the reading on MSA, MSA, a lot of discussion in the reading is really about, well, MSA does this, but really what we're saying is that MSA, if you're practicing MSA the way it's described, is SOA done right on a small scale? Sounds like a good definition, SOA done right on a small scale. I think we've touched on SOAP versus REST. We've certainly touched on microservices. So unless either of you want to expand on those any further, maybe we can move into more of the questions that have been coming up. Is that okay, John and Nathan? The one thing I want to add with SOAP versus REST is it is possible to use SOAP in a RESTful style. And REST does not have to be tied to HTTP and it is possible to use SOAP RESTfully. I think that's a very good point that REST is not as such a protocol. It's a philosophy, as I understand it anyway. And as you say, it could be used with SOAP or other protocols. Okay, can we move on then? There are a number of interesting questions here and I'm not going to take them in any particular order, but perhaps I could go to one that's asked by Cesar Mercado, how do other digital enablers such as mobility, social, big data and analytics and the Internet of Things affect SOA? Sure, so in all those areas, especially when it comes to Internet of Things, mobility and so on, the need for exchanging information in a timely manner, the need for exchanging data in a timely manner and then realizing value out of that data is what, you know, big data and taking action based upon the insight gained is really what big data is all about. And Internet of Things is just expanding the universe of data sources. The reason why I laid that context first is because the need for interoperability has only been exponentially increased, which is something, one of the fundamental concepts enabled by SOA. So I would say the impact that SOA has had is really in channeling and, you know, growing that fundamental thought process, the need to interact, interface and exchange data in a timely manner, whether it be mobility, whether it be IoT or big data, social media and so on, that need has only been accentuated. So SOA is definitely a foundation that has taken us there and continues to do so from a conceptual standpoint. So I look at IoT as being a classic example of where SOA can be a big winner. Think of a small device and I'll use a thermoset as an example. A hotel with 250 rooms typically has 300 thermostats in the hotel, one for each room and several over common areas. And they tend to want to manage these in a central location. You don't want to have to go visit each room to change the thermostat. You don't want to have to go to the room to find out the room's too hot or too cold for the guest. So the question then becomes, do you have that thermostat sent a message periodically to a service that's listening for that message? Or do you query that thermostat when you want to find the temperature of the room? If nobody's staying in the room, do you really care? And these kinds of things, the beauty of web services, they give you the flexibility to change the architecture according to what your needs are for that particular solution. And this is where the real power for IoT and web services comes in. You can do that integration, but you can do that integration using an event-style system, using a polling-style system with the device being the source or the device being the end point, the requester. It allows you to have a lot of flexibility with how you do this integration using a very small set of rules. And that's where I see the power for SOA in this context. Okay. Can we maybe take another question from Shailesh Sohoni? How do you see SOA servicing its business use case, especially in big data environment? As you may have structured, non-structured data in multi-terabyte size, I can really concern whether SOA can help servicing the data needed in this use case. Can you comment on the value of a service-oriented approach when the size or velocity of the data it is dealing with is enormous? There are a couple of solutions. Again, this is something that I see commonly in the hospitality industry, which is where I support and do a lot of my work. There are a couple of solutions that are common. One is, if I'm going to look at, say, streaming a video stream, I need to set that up. Services are a good way of doing that setup, and then I'm going to stream directly to my endpoint. The other thing is, don't think necessarily of a service as being something that always implements XML or always implements REST and JSON and all that type of thing. When I'm streaming that data, that data's got to have some place to go. I'm setting up two ends of the connection. And so that streaming is actually being handled through a service that's delivering that streamed information to that endpoint, which is your television, your mobile device, that type of thing. The other thing, we have to deal with this a lot in the hotel industry because for years it was traditional just to do large bulkfall transfers to move daily data between systems, and there are a number of reasons why that is not always the most desirable way to do. And then what they do is they use a web service that batches those bulk transfers up and basically acts as a protocol on top of the network layered protocol in order to batch that information up and send it in a way that guarantees delivery, guarantees consistency, those types of things. So the big data, I'm not sure I've got a good answer for you. Both so long if it's not on the granular level but it's at the high level dealing with the direction of streams and so on, then so it certainly has a place I think is what you're saying. Do you want to add to that now then briefly? Yes, so I would actually request the person who asked the question and others to look at the first technical standard on the service-oriented cloud computing infrastructure from the open group. And the reason why I bring that up is because the case study that we used when publishing that paper was about uploading auto-racing videos and we have looked at doing that as a technology provider, as a service provider using a service-oriented approach and you will see how the alternative, the various choices are factored in. And to Chris, the point that Chris summarized just now, the fundamental concepts of availing various services has not gone away. If not anything else, big data, the need to work with structured and unstructured data has only proliferated the need to work with the right services, the right service providers. So those concepts are very much there today. So from that standpoint, SOA is a fundamental enabler and continues to be so. So I would really suggest you go and take a look at that so that that will shed some more light. But that being said, if you think of SOA as a technology solution, what we started with in the original days, that may not hold good as much. We have evolved. But then the concepts, though, have only been reinforced and definitely apply even in the case of big data, unstructured data, mobility, and so on. And so when you look at big data, if you're trying to retrieve a data item and think of CouchDB or Berkeley, the old Berkeley CBCAT DB, when you're trying to retrieve an item, essentially you're giving it the key, you're retrieving the item, item can come back as, I believe, Couch automatically returns as a JSON object. It can come back as an XML document. It could come back as an IDL object. Essentially, those large data databases for retrieving data are exposing web services. When you're talking about the operations that happen on the data, doing the slicing and dicing, you're also talking about services, but how those services get processed by the requester is going to be unique according to what your application needs are. So that's, I think there's a lot more that could be said on this topic, but we are actually drawing to the end of the hour. So let's move on. And can I ask you both this final question, if you could say a few words briefly? Do you think the main concepts of SOA have changed? Is today's SOA fundamentally different from the original? And if so, in what big respects? I can go first. So the answer to the first question, the main concepts of SOA have not really changed. Of course, it depends on what level of abstraction you look at, but I would say fundamentally the concepts that originated the need for SOA and what it has evolved to, those concepts have not changed. However, what has changed is that it has definitely been commoditized, so it is a lot more prevalent and much easily, much more available, but there is also a level of maturity that we have grown to where there is a realization that we need governance, we need proper architectures, we need the policy enforcement security and managing the list of services so that we have the services that are used for good business reasons rather than just creating a proliferation of services. So the need for that type of governance has that end, is there today, which was not there when it originally started, and cloud has actually accentuated that need, so it is not just the governance around SOA, but also governance for cloud. And just like what John said earlier about, SOA is an absolute, it was a prerequisite for cloud. I would say SOA governance is actually leading up to doing cloud governance right as well, so those would be my answers, Chris. Okay, thanks, Nadine, that's a clear answer. John, do you have thoughts on this? Yeah, I believe that SOA has grown up. So when you look at SOA in the early days, compare it to a baby head-to-head, had two arms, two legs and a body, a German leg had five toes on each, five fingers on each hand. From that standpoint, when it's grown up, all those fundamentals are still there. It still has five fingers on each hand, five toes on each foot, so on and so forth. But there are different needs. Now that it's grown up, you have the ability to use it as simply as it was in the beginning. But because it's grown up, it is now used for far more complex things than it was originally imagined for. Because of that, now all of a sudden you need more governance. You've always needed some governance, but now you need more governance. You need governance that's right-sized for the problem. You want to manage that complexity. That means you want to make sure that you understand who's exposing the services, who's consuming the services, how are the services being transformed, who's monitoring services, give you insight into core business processes. So from a business standpoint, just like I wouldn't run a website without looking at the web logs and analyzing and processing the web logs, I wouldn't want to have a service-oriented architecture where I didn't have the ability to observe what was going on with my services. All of these things, because of the increased size and complexity, have added these needs into that environment. Even if you have the pushback, those needs are now being done in different ways, but they're still being satisfied. So yes, it's changed, but the core concepts. I've got a standard way of interfacing. I have a standard message. I've agreed on what the message is going to be on the consumer and the provider side. I can do that exchange. I can make a request. I can get a response. Or I can make a request that I know that that endpoint is going to do something with it, whether I get it back or not. Those things are fundamental, and they have not changed. But the services have grown up, so has grown up, and with that becomes the responsibility of an adult. Okay, so I think from both of you, there's a feeling that so has not changed fundamentally. It has become more technically mature, maybe from we haven't reached the technical advancement of the space shuttle yet, but we're probably up to the 747, something like that. It's a robust, useful technology. There's been some great discussion in this webinar. This was the first of the series, Developed in Soho, where we really looked at how Soho has changed to now. I would like to conclude the webinar. I'd like to thank our two panellists, John Bell and Madden, and apologies that Ali could not be with us. And to everybody who has questions, there are a huge number of questions, and also actually some people have answered them on the chat. So thanks to everybody who asked those questions, who provided answers, and to everyone who participated, as well as our two panellists. And I look forward to seeing you all again in our next Soho Individual Age webinar on the ISO Soho Reference Architecture.