Enterprise Software

Enterprise benefits of a service-oriented architecture using Web services

A consultant who implements service-oriented architectures for his clients explains their strategic advantage. If you're trying to make the SOA decision, his advice may help.

For the past nine months, my consultancy has been introducing our clients to service-oriented architectures (SOA) using Web services. We chose to move into the field of integration to solve our customers’ biggest issues, namely a lack of communication between applications. Their recent mergers and acquisitions only seemed to intensify this problem.

At first, my company focused on data integration by creating operational data stores and metadata repositories. Our clients would smile and thank us for reducing their reports from 16 pages to one page. However, we knew they really wanted integration, with all applications containing the same data. They wanted duplicate data entry to be a thing of the past. They wanted mergers and acquisitions to be painless. They wanted independence from ERPs. They wanted all their applications to communicate in real time.

Service-oriented architecture
We began exploring Web services, with which an application could expose its functionality to the external world. This sounded good, but how is it managed? Would application functionality be exposed, creating a free-for-all? Integrations must make sense. What data does one application need from another? For example, shipping needs to know when an order is created and expected. Manufacturing needs to know when an order comes in and whether shipping has enough products to meet the order. We identified these factors as integration points.

With our SOAs, we began creating the "brain matter" that could manage and contain the neurons that allow information to synapse all over the enterprise. Each neuron is a different system that communicates with other neurons through Web services. Currently, companies that want to harmonize their IT applications create a giant neuron by purchasing the all-encompassing ERP. Their reasoning is that if you can’t buy applications that can talk to each other, buy one big application that does it all.

Stop replacing and start leveraging
The major problem with mergers and acquisitions is integrating everyone’s information to leverage the strengths of both companies. Quite often, I have walked into subsidiaries that behaved very independently from the parent company, because both companies had completely different systems and no one could figure out how to inexpensively integrate or replace their software with the parent company’s systems.

SOA allows companies to leverage each member’s existing technologies rather than replace them. SOAs using Web services are noninvasive. After the SOA has been put into place, the company with the SOA can explain to other companies how to plug in. The parent company can plug into the subsidiary to obtain its information and vice versa. A company can use the SOA to enable B2B transactions.

Stop costly implementations and start small integration projects
Another benefit of Web services is the ability to start small and grow big. Normally, a software implementation is an all-or-nothing scenario. Web services allow a company to move at the pace it can afford. On my last implementation, we defined the core data that we needed to harmonize between different applications. After the initial pilot, we prepared for the second round of integrations. We used open source software for the pilot, so that our client wouldn’t be left with an expensive piece of software if the pilot was unsuccessful. The only costs were those for consulting fees, which could be terminated with 24-hour notice. Now that the SOA concept was proven, our client was more confident of investing in middleware to aid in administration.

Stop being vendor-dependent; be strategically competitive
Another great benefit of Web services is the independence from ERPs. When we first started at one company, the client referred to all non-ERP applications as legacy systems. These legacy systems were irreplaceable and provided substantial benefit to the company. We would argue for hours with the pro-ERP people (the ERP developers) that the systems needed to be integrated. The ERP developers wanted the users to change the business so that they could use the ERP. The decision was made by the users to integrate the two applications using Web services. It took two months with heavy resistance up front.

We understood the fear of the ERP developers, because the CIO saw the light. He didn’t need one vendor that did everything. He could now search for applications and solutions that best gave his company a competitive advantage. “If every company has the same ERP, how does one achieve competitive advantage?” he asked me in the elevator. Now he can replace any application with another and doesn’t have to worry about which vendors offer the most extensive suite.

Stop being batch and start being real time
Your employees and customers communicate in real time, why shouldn’t your applications? At another recent implementation, we were sent into a company where all the employees looked like zombies. The company ran on a batch processing workflow system. Each night, the batches would run to feed the next process in the processing of orders. All the batch processes started at 12:01 A.M. Twice a week, they would fail at 3:00 A.M. The company’s developer would be notified via pager. He would then wake up a half-dozen other developers to determine the error. There’s nothing like a game of finger pointing at 4:00 A.M. They would solve the problem, then kick the jobs off again at 6:00 A.M.

The batch jobs took eight hours to complete and would not finish until the workday was practically over. Each part of the process would be 24 hours behind schedule. At 8:00 A.M., the developers would go into work and stay a normal eight-hour day. “By Friday the department looks like 'Night of the Casually Living Dead Day,'" complained the CIO in our first meeting. “These developers are so exhausted, they break everything they touch. I wish they would stay home on Thursdays and Fridays,” added the operations manager.

We built a SOA to transform our client’s batch environment to a real-time environment. When systems failed, they failed at 12:01 P.M. and people could correct the problem by 12:10 P.M. and still go for lunch. Also, as soon as the sales team enters an order, the order management department immediately receives it.

Editor's Picks