By Guest Blogger Philip M. Troy, Ph.D.
Consider that you have several systems supporting your manufacturing ERP operations, but they are not all from the same vendor, or even from vendors that provide compatible systems. Or, you wish to add another capability to your existing set of systems, and the best available one is not compatible with your other systems. All of the systems individually do what you need and do it well, but if you could get them all to talk directly to each other, the results would be even better.
Unfortunately, many systems today are not designed to work well with each other. Therefore, when your IT staff tries to get the different systems to talk to each other, that are not explicitly designed to do so, it can be very difficult, if not impossible.
To avoid this situation, you have two choices. First, you can buy all of the different systems from the same vendor or you can buy from different vendors that provide add-on modules for that vendor. If some of the systems from the vendor work well and others don’t, you will not really achieve your goals.
SOA To The Rescue
The second alternative is to buy systems, designed to provide specific services, and to make those services available to other systems via well defined interfaces. This can be thought of as being like code phrases, and responses to those code phrases, that everyone understands. With such a capability it would be possible, for example, to use one system to track the status of all outstanding orders, a second system to request a list of those orders via the first system’s well defined interface for supplying them, and for the second system to then use that information to determine the best sequence of operations to fulfill those orders on time. Likewise, with the same type of capability, the second system could then talk to a third system, via that third system’s well defined interface, to tell it which items needed to be picked when. This is the concept behind SOA, Service Oriented Architecture.
Service Oriented Architectures are often implemented as web services. In a nutshell, web services are provided by computer servers that respond to requests submitted in a format called XML (which looks a lot like HTML, the language used to describe web pages) with responses also formatted in XML. For example, a request for all current orders might look like this in XML:
and the response might look like this
<task type="A" quantity="100"/>
<taskInput itemNo="3756" quantity="27"/>
<taskInput itemNo="24999" quantity="54"/>
<task type="B" quantity="100"/>*
<taskInput itemNo="7356" quantity="32"/>
<taskInput itemNo="42999" quantity="97"/>
. . . more open order data
Conceptually, the use of XML has two components, that of a document that specifies the format of the data, and another document, the actual XML document, that contains the data in the specified format. By predefining the format in a structured manner, other programs can access the data. Because XML is standards and text based, it tends to be easier to understand and for software developers to work with.
Finally, it is important to note that web services and XML are not the only way of implementing Service Oriented Architectures, and that there are in fact a variety of technologies that can be used. And even more important is the concept that by using well defined interfaces to service oriented system capabilities, it becomes possible to communicate between different systems so that they work together as effectively as possible.
SOA is not new but is being recognized more and more as an important technology tool in order to provide effective, well integrated ERP solutions for today’s demanding requirements.
About the Author
Philip M. Troy, Ph.D.
Process & Quantitative Decision Support/Systems Analyst
Les Entreprises TROYWARE