|
The buzzwords and acronyms I'm about to mention are already very familiar to you. Not to be too gestalt about it, but in the case of SOA, the whole is greater than the sum of its parts. Having said that, here are some of its parts:
Enterprise service bus (ESB): An ESB manages the flow of messages across different applications, orchestrating communications and allowing, for instance, an MDM hub to access application messages and data. It's not for data integration; rather, it's a messaging mechanism.
Service registry: A service registry is critical for an SOA environment in order to track and publish services to applications developers, business partners and exchange members so they know which services exist and how they should be used in the form of service metadata.
Business processes: Without business processes, SOA is just a framework comprised of the above pieces. A business process can be in the form of a Web service (e.g., "Update the customer's address" or "Change the product's name"). The point of SOA is to unify these processes across systems and make them repeatable.
MDM hub: You knew I'd go here, didn't you? As I've written before, an MDM hub provides a means for reconciling common master data across systems and applications, providing an operational single version of the truth for customer, product, location or other reference data. Master data management ensures that the meaning and format of the data being accessed is unified across all the applications that access the hub; the data is understood by all the services that access it.
Data management: If your services are information-rich then data management is a must. Since the data that services access might not necessarily come from an MDM system but from a range of applications and databases, managing, tracking and maintaining that data at the enterprise level is a critical component of SOA. This means having business rules, policies and metadata used and enforced.
|
