Service Oriented Architecture (SOA)

Things change. Sometimes for the better. Sometimes for the worse. Sometimes we can control the changes but lots of times we can’t. Our kids grow up. We grow old. People you know and love move, divorce, get sick or die. Little we can do about many of those things. Life happens as they say.

There’s a big movement on in Industrial Automation. Many probably don’t see it coming but times are changing. Smaller and more powerful microprocessors. Ethernet connectivity for EVERYTHING. More data, more integration, more, more, more automation. And all that is going to change how we do our jobs and the skills we are all going to need in the future.

There’s lots to learn. Service Oriented Architecture (SOA) is one of those things. It’s a term were all going to know (but probably not love) in the future.

SOA is not a protocol. It’s more of a strategy for connecting resources across and enterprise and it’s rapidly moving down the organization toward the drives, valves, HMIs and other end devices that we work with every day. SOA is a way or organizing and distributing resources. It is a way to offer, discover, interact and use the capabilities of a resource in a way that is common among many types of resources.

So, where is this coming from? SOA is an IT philosophy developed to link silos of information systems together. Imagine the IT problem, we have an ERP system here, an Accounting system there, a CRM system over here. Linking these one at a time with custom interfaces is a nightmare. The SOA strategy overcomes this and drives faster implementation and lower costs by making the resources of distributed systems and devices available in standard ways.

Let me give you an example. There is a new train being developed in France. Every component (hardware, software, whatever) is being implemented as a SOA device using one of the implementation standards. When the train pulls into the station, supervisory software can quickly and easily interrogate every part of that train to diagnose problems and develop a maintenance plan for it. And if a new component is added, that component can be easily added to the system. And since it is all standard IT technology there is no special training required, no custom software to support and no obsolescence issues to worry about.

The basic tenets of the SOA strategy are:

1.       Separation of the service interface (the how) from the implementation of the resource (the what). Clients that consume these services are not concerned with the implementation.

2.       Services can be dynamically discovered.

3.        Services are self-contained (perform predetermined tasks) and loosely coupled (for independence).

4.       Composite services can be built by aggregating the services available from a set of resources.

In a SOA system, resources register their services. A consumer uses the registry to find the services that it requires. Once a service is found, the consumer gets a contract and an endpoint address for the service.

WebServices is one of the most common ways to implement a SOA strategy. In fact, the train example I referred to earlier uses Web Services for its implementation.

Change is coming. SOA is one of the things that is going to change how we do business in the future. We might as well get comfortable it – it’s not something we can stop.