 As we have discussed in previous sections, the structure and makeup to complex engineered systems is fundamentally different to that of our traditional engineered systems, which are homogeneous, well-bounded, monolithic, and relatively static. Our complex systems are, in contrary, heterogeneous, dynamic, unbounded, and composed of autonomous elements. Developing and designing these new complex engineered systems requires in turn an alternative paradigm in systems architecture. Our new architecture will need to be able to deal with the key features to complex engineered systems that we discussed in previous sections. Firstly, it will need to be focused on services over the properties of components. It will also need to be focused upon interpretability and cross-platform functionality to deal with a high level of diversity between components. So as to deal with the autonomy of the components, it will need to be flexible, distributed, and what we call loosely coupled. Lastly, it will also need to employ a high level of abstraction to be able to deal with the overwhelming complexity of these systems. Over the past few decades, a new systems architecture paradigm has emerged within IT called service-oriented architecture. It is a response to having to build software adapted to distributed and heterogeneous environments that the internet has made more prevalent and thus is an architecture paradigm that fits the design of complex systems well. Service-oriented architecture, SOA, or SOA for short, is an approach to distributed systems architecture that employs loosely coupled services, standard interfaces and protocols to deliver seamless cross-platform integration. It is used to integrate widely divergent components by providing them with a common interface and a set of protocols for them to communicate through what is called a service bus. Because SOA originally comes from software development, let's take an example from IT. Imagine I want to build a new web application that allows people to pay their parking tickets online. Well, I could spend years developing a subsystem that functions as a street map and then another subsystem for dealing with the payments and yet another for login, user authentication and so on. Or I could simply avail of Google's Map Service, a payment gateway service from PayPal and a user login service from Facebook. My job then would be to integrate these diverse services by creating some common process that guides the user through the use of these different services to deliver the desired functionality. Thus, instead of building a system that was based around all my different internal components within my well-bounded piece of software, my new application would instead be built with an architecture that is oriented around services, a service-oriented architecture. Now let's take an example outside of IT to illustrate its more generic relevance. Imagine I'm a coffee shop owner. My interest is in providing customers with food and beverage in a pleasant environment. In order to do this, I need to bring many different things together, from coffee beans to equipment to employees and so on. I need to design some common platform for all these things to interoperate and deliver the final service. But let's think about this system within the more formal language of SOA. Firstly, each component in the system is providing a service, whether it is the employee pouring the coffee or the chairs on which people sit. We as designers of the system are not interested in the internal functioning of these components. Because we don't need that information, we abstract it away by encapsulating it. Only the provider of the service needs to know the internal logic of the component. To us, they are simply services. So when it comes to a customer paying with a credit card, they simply swipe their card and input the pin number. No one in the shop understands how the transaction is actually completed. Only the financial service provider has that information. For the rest of us, it is abstracted away through encapsulation. We may also note that the financial service provider has almost complete control over the logic they encapsulate, at least during the system's runtime. As is the case for many other components in the system. This is called service autonomy. What we do need to know, though, is what function the component serves and how to interact with it. We call this an interface. When one of our new employees picks up a packet of coffee, she knows what it is and how to use it because it has a label. We may also note the big yellow sign above the bin in the corner, encouraging customers to dispose of their waste. This is called service discoverability. Services are supplemented with communicative metadata by which they can be effectively discovered and interpreted. We might say our bin is broadcasting the availability of its service. Although I have employed a multicultural team of staff, there is an agreement that everyone will speak English when interacting with other staff on the shop floor. This is called a standardized service contract. Services adhere to a communications agreement as defined collectively by one or more service description documents. As part of my business, I have a network of suppliers and maintenance people. If I need more personnel, I call the recruitment agency and I will have a new employee starting next week. If the shop needs painting, I can call my decorator. If I need more tables, I can buy them also. All of these different services are what is called loosely coupled to the system. This means these different modules can join or leave, couple or decouple from the system as need be, thus maintaining their independence. This loose coupling allows for the dynamic provisioning or deprovisioning of resources to maintain an effective systems load balancing mechanism. Lastly, once my little business is up and running, generating revenue, I might want to start another one or maybe another 10. But this time in say the restaurant business or maybe a confectionary. The great thing I notice is that I don't have to start from scratch each time. I can just extend my insurance contract, order more tables, use the same bank account and so on. This is called service reusability or composability. Because the services are independent from any particular process I compile them into, that is to say any of the stores I set up, they can be endlessly reused, composed and recomposed into new configurations. Okay, so we've spent a lot of time talking about a little coffee shop and replying formal SOA to a relatively simple system like this is a bit overkill. The real value arrives when we scale things up to the world of complex systems, to the architecture of large enterprises, designing urban environments or even whole economies. Because of its abstraction, the same architecture can underpin our design on the micro level as well as the macro level. We have a set of heterogeneous components. These components might be people of different cultures in a society. They might be different modes of transportation within a city. Or they might be different devices connecting to an Internet of Things platform. We create a generic language that can be used to describe all the components in the system and their service. We create interfaces for the components that translate their local language or functionality into the global language. We give them a descriptor to describe the components functionality, availability, terms, conditions, and various other parameters to its coupling and service provision. We create a service bus that integrates these functional components into an entire system and we create an interface for the end user to interact with the services they need. We can wrap up by saying, SOA should be seen as our architecture paradigm of choice when doing systems integrations within complex engineered systems. It provides us with a formal language that has sufficient abstraction for the many different applications we might be using it for. This high level of abstraction also works to maintain the autonomy of components, another of our key considerations. It is inherently relational, which again suits the network nature to the complex systems we're trying to design. And as we will be discussing in later sections, it can be optimized for an event driven architecture that suits well the dynamic nature of complex systems.