At Washington Group, SOA Extends ERP

SOA in Action Blog

« Governance Matters: Avoiding 'Service-Oriented Anarchy' | Main | Two of a Kind: SOA and Web 2.0 »

September 21, 2006

At Washington Group, SOA Extends ERP

There's been some talk across the industry lately that SOA could usurp the functions of enterprise resource planning systems.

Rich Colton, application integration manager with Washington Group International, doesn't necessarily agree that SOA will vanquish ERP. Nevertheless, his company is deploying service-oriented architecture to effectively fill in the gaps left by ERP systems.

I recently had a chance to chat with Colton about this emerging role for SOA. His company, based in Boise, Idaho, provides engineering, construction and management for projects ranging from bridge construction to weapons destruction. The company had gone through a number of mergers in recent years, and therefore was left with multiple proprietary, custom-built and packaged applications. But a single environment did not exist that could fulfill the various roles these systems played.

"We have not found an ERP system that meets the engineering/construction industry's requirements," Colton says. "Several have tried, including both Oracle and SAP. We found they really didn't offer the kinds of products that we need in different areas, such as project management, project controls, estimating, or materials management. We ended up having to use the best of breed in different areas. Up until now, it's required a lot of duplication, triplication, and more, of information from one system to another."

Washington Group employed Oracle Fusion middleware to move to an SOA that would abstract many of the functions used across the company into a common service layer. "By integrating these systems, we can -- on the back end then on the front end -- build some business processes that aren't being executed within the legacy application execution systems, and have it done in a layer above that. We can then update the appropriate systems where needed."

What was Washington Group's greatest challenge in its SOA deployment? Colton says that his team faced many issues around getting .NET and Java EE environments to interoperate. Washington Group's back-end systems run on Java EE, but they need to connect with desktops at the front end. "We write most of our Web services and our back ends in Java for the Java EE environment. Our client side may be .NET as well as Java clients. We have to ensure that our Web services are consumable by both environments."

"What we found still is that the vendors choose which portion of the standard they want to implement. So we've had to work though those issues."

Colton also reports that efforts to encourage reuse of the components have also borne fruit. "The issue is understanding your business, and what components you need to build that you're going to orchestrate," he relates. "That's what we've done. We've built some reusable components that we use in a number of different processes that we've developed, and we've been able to use those same components over and over again -- so we don't have to rewrite those components."

For example, Colton's team helped develop a document control service that gets widely reused across the company. "Document control is a big part of our business, because we interact with so many clients, subcontractors, vendors, and government agencies. Every project has to manage every piece of information going in and out. We track it all; whether it's paper or emails."

Washington Group uses EMC's Documentum system to accomplish this. "In the past, to use the Documentum API, we had to build point-to-point connections between applications the Documentum backends. With Web services, we only had to implement that API in one place, then built a series of components around a Web service that our applications can use. These applications just call the Web services, instead of building an API in their environment."

Posted by joemckendrick in SOA | Digg This | Add to del.icio.us