Service-Oriented Architecture: Efficient, but Threatening?

Getting software to do the actual work of business has never been easy. Perhaps the most aggravating limitation of business software is the seeming inability of applications to accurately embody the strategy and everyday processes of the business, and to keep pace with business-process changes.

To a large degree, this is because traditional, so-called “monolithic” applications are made up of individual business functions that were designed, developed and deployed to operate only in that particular application. In a manufacturing setting, for instance, the process of monitoring raw-materials inventory might support inventory replenishment as well as production scheduling and accounts payable.

The business functions that make up this process might include identifying materials, noting when inventory is used, sending an alert when inventory dips below a certain threshold, and so on. Each group has its own reasons, and its own application, for monitoring inventory, yet the process is essentially the same. Or at least it should be.

What’s more, the developers of each of those applications may have had their own ideas about how a particular process should work, which means that a given business function would be defined inconsistently from application to application. Worse, a change made to one application may never be reflected in other applications. The proliferation of applications as businesses grow, acquire other businesses, and add new delivery channels, products and the like, only compounds opportunities for miscommunication and inefficiency. Fold in the growing number of digital interconnections with customers, suppliers and other business partners, and it’s enough to make any CIO’s hair hurt.

Meanwhile, in the mid-to-late 1990s, many organizations went on a spending spree, purchasing large packaged application systems such as ERP and CRM. Vendors claimed to provide the middleware and other software necessary to integrate plodding legacy and in-house applications with their shiny new packaged application systems, but those enterprise application integration efforts only exacerbated the problem.

Using EAI, IT organizations did manage to integrate disparately designed and developed applications, but the connections they set up between those applications are often inflexible, or hardwired, and difficult to change in response to business conditions.

“Many organizations are suffering from a 1990s hangover,” says Michael Liebow, vice president of Web Services and SOA at IBM Global Services in Somers, N.Y. Liebow adds that the upshot of excessive investments in systems and the resulting integration efforts is that “80 percent to 90 percent of their IT budgets are going to maintaining the status quo.”