Service-Oriented Architecture (SOA) - dummies

By Thomas C. Hammergren

If you establish more data integration by using ODS and MDM data stores, you also need a messaging, or communication, architecture to enable systems that weren’t built to communicate with each other to do so. Enter the concept of service-oriented architectures, or SOAs.

SOA is a method for systems development and integration in which functionality is grouped around business processes and packaged as interoperable services. SOA also describes IT infrastructure that allows different applications to exchange data with one another while they participate in business processes.

An SOA aims to loosely couple services with operating systems, programming languages, and other technologies that underlie applications. This process is very similar to what happened with audio visual equipment while it evolved.

You can buy the best speakers for your surround-sound system, hook them up to your audio-visual receiver, hook the receiver up to a high-definition projector, and operate it all with a universal remote. The interfaces between these components has been standardized so that different manufacturers can interoperate with each other’s “best of breed” components.

SOA separates functions into distinct units, or services, which are made accessible over a network so that the run-the-business and monitor-the-business applications can combine and reuse those functions. Ultimately, these services reside in the integrate-the-business layer.

These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. SOA concepts are built upon older concepts of distributed computing and modular programming that advancement in various technical infrastructure components and general software engineering have made possible.

SOA provides messaging as a mechanism for moving data (in this case, master data) from one environment to another. Regardless of the products and technologies you use, take a look at cross-system messaging architectures.

Messaging is typically an asynchronous means of communications from one environment to another. The source of the message (in this case, the application in which someone makes an update) can continue with its own work without having to hook up with the recipient of the message (in this case, the MDM system).

The messaging system and its associated protocols handle verification and validation services. Messaging and asynchronous communications give you a great deal of flexibility in architecting distributed environments in which you must send data back and forth across systems quickly and can’t afford to tie up any one system while it waits for another to do whatever it needs to with the message.

MDM, along with SOA, provides you the technology platform to deliver a number of feedback loops between several different operational data stores and your run-the-business application portfolio. MDM helps resolve the problem of point-to-point data integration between systems. Before MDM implementations, point-to-point solutions typically resulted in a spider’s web of communication lines that were complex to manage and maintain.

MDM and SOA provide a robust alternative approach that implements a data message hub architecture which serves as a collection and distribution point for messages across your enterprise.

Each application then publishes (makes available) a certain set of messages and also subscribes to (accesses) other messages that might come from other applications. Each hub keeps a list of which applications are subscribing to which messages and, after receiving any message, distributes that message to the appropriate destinations.