As we have discussed in previous sections,
the structure and make up 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.
Modeling and designing these new complex
engineered systems requires intern and
alternative paradigm in system 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 interoperability
and cross platform functionality,
to deal with 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,
S.O.A., or SOA for short,
is an approach for 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 on line.
Well, I can spend years developing a subsystem
that functions as a street map,
and then another subsystem for dealing with the payments,
and yet another for log in,
user authentication and so on.
Or I could simply avail of Google’s maps service,
a payment gateway service from Paypal
and to use a log in 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 diverse 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 am 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 a 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 simple 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 it is the case for many of the 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 standardised service contract.
Services adhere to communication 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, a 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 compiled 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 have spent a lot of time talking about a little coffee shop
and applying 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 microlevel
as well as the macrolevel.
We have a set of heterogeneous components.
These components might be people of different cultures in the society,
they might different modes of transportation within a city
or they might 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 translates 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 are trying to design.
And as we will be discussing in later sections,
it can be optimised for an event driven architecture
that suits well the dynamic nature of complex systems.
