Every automation solution, regardless of platform, represents a collection of features and functions designed to execute some form of business process in support of one or more related tasks. The requirements for which such a system is built are generally well-defined and relevant at the time of construction. But, as with anything in life, they are eventually subject to change.
There are many drivers of change in contemporary corporations. Here are some of the more common examples:
- The expansion of an organization's business areas. When organizations undergo periods of growth, their business interests often broaden. This can include the incorporation of ancillary business operations that supplement their primary line of business, or it can go as far as the assimilation of entirely new business areas. These may or may not be related to the organization's primary goals but will almost always end up impacting the underlying technology environments responsible for automating the original business processes.
- The contraction of an organization's business areas. Corporations sometimes are forced to cut back on the scope of their operation. This may be a required response to changes in the general economic climate or changes in an organization's immediate business environment (such as the arrival of a new competitor or the loss of a primary client). Regardless, a reduction in business scope will require significant adjustments to existing business processes. These, in turn, can result in major changes to underlying automation logic. It is important to note that business area contraction is not always synonymous with a reduction in an organization's size. Sometimes, organizations simply eliminate some business areas to increase the focus on others.
- The acquisition of one organization by another. This situation obviously brings with it a multitude of issues, as the incorporation of a company's assets into an existing environment requires coordinated integration on a number of levels. Affected business processes typically are augmented or remodeled entirely, as is the supporting automation logic. Most integration issues arise from the introduction of foreign data models disparate in design and content.
- The merging of two organizations. This situation may require different integration requirements than the acquisition scenario. A corporate merger may not result in a clear cut relationship between two organizations, in that every merger is based on some form of operational agreement. The resulting requirements can include direct integration or even assimilation of automation solutions, but they also will very likely introduce the need for some form of cross-organization collaboration.
As the business arena becomes increasingly "global," these events are expected to become more common. Because of their magnitude, they can impose a great deal of change onto existing business automation environments. This is the primary reason that organizational agility has become so important.
When the extent of change is so broad that it affects multiple processes and application environments, it tests an organization's ability to adapt, for example:
- Cross-platform interoperability The ability of previously standalone applications to be integrated with other applications that reside on and were developed with different vendor platforms.
- Changes to cross-platform interoperability requirements The ability of existing integration channels to be augmented or replaced entirely in response to technical or business-related changes.
- Application logic abstraction The ability for existing application logic to be re-engineered or even replaced entirely (often with new underlying technology).
The agility contemporary SOA brings to an organization can be fully leveraged when building integration architectures. The many benefits and characteristics we identified in this book as being attainable via SOA outfit the enterprise with the ability to meet the challenges we just explained. Service-oriented integration therefore empowers organizations to become highly responsive to change, all the while building on the service foundation established by SOA. (Service-oriented integration is explored in the companion guide to this book, Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services.)
Figure 18.23. Disparate solutions communicating freely across an open communications platform. A testament to the inherent interoperability established by SOA.