10 best practices for your enterprise SOA

Early adopters share top tips for building service-oriented architectures

The benefits of the service-oriented architecture are widely touted: reduced integration costs, greater asset reuse, and the ability for IT to respond more quickly to changing business and regulatory requirements. But what about the pitfalls?

SOA pioneers know all too well the challenges that can arise when a company service-enables critical applications. The SOA endeavor spans IT disciplines: It's part systems design and architecture overhaul, part application development and business makeover. Here, early adopters and other experts give their best advice about avoiding the obstacles when building this New Data Center essential, the SOA.


Read a related story on SOA expertise wanted.


1. Start with a process that previously has been opened.

Knowing what SOA project to start with could be a matter of finding a receptive audience, says Joseph Gaus, enterprise architect at Dow Corning in Midland, Mich. "Early on, target systems that people are used to having applications built around," he says. For example, SAP is the master system for many of Dow Corning's most critical business processes, including its order-to-cash process. In the past, the specialty chemical company has let other systems tap into that process - for example, a Web-based application that lets customers place orders online. "We're used to opening up that process, and the people who support that process are a little bit more comfortable having other applications built around it," Gaus says. Plus, the process is entwined with multiple applications so there's an opportunity for reuse, he says. "You can demonstrate SOA's value more easily with such a process."

2. Don't take interoperability for granted.

When Washington Group International began its SOA implementation three years ago, standards and tools weren't as mature as they are today. A key challenge was building Web services that could be consumed by both Java and Microsoft .Net clients, says Rich Colton, application integration manager at the Boise, Idaho, engineering and construction company. World Wide Web Consortium (W3C) standards could be implemented in different ways in Java 2 Platform Enterprise Edition than they could in .Net, Colton found. For example, the two environments handle the standards for a Remote Procedure Call differently, and each supports different message payloads, or content. "We discovered early on that interoperability is a nice word, but the actual implementation left something to be desired," he says. "You can't always do what the W3C standards say you can do, because not everybody has implemented all the pieces." Over the last few years, interoperability has improved a lot, but it's not automatic. Testing is critical for programmers, he says.

 

3. Don't open your wallet too quickly.

When IT embarks on an SOA project, the first thing it often wants to do is buy new technology. But before committing to a technology platform, IT needs to identify all information sources and make sure it documents how each system defines data, says Dave Linthicum, CEO of SOA advisory firm Linthicum Group. Without due diligence, a company might select a governance tool that, while impressive, may not jibe with the final technology layout, service management requirements and security strategy. "Everything is interrelated. You need to understand the data, the services that interoperate with the data, new services you need, and then the processes to which they're bound," he says.

4. Think governance.

Building a new framework for an entire corporate infrastructure is no easy task. Trial and error is part of the deal, says Bryan Grant, lead application integration developer at DaVita in El Segundo, Calif. DaVita provides kidney-dialysis services via a network of about 1,255 outpatient centers, each of which generates data that is collected in a central location and made available to multiple applications, he says. It has been tough to change from point-to-point connections to a more open platform that lets distributed IT teams reuse applications, deliver new services, and link legacy and packaged applications. "You can never expect it to work the first time out," he says. DaVita is concentrating on improving governance - knowing what systems are connecting, and ensuring services put into production belong in production - and ultimately will buy software to help do that. "We were not good at governance in the past," Grant says.

5. A little incentive never hurts.

Over the last few years, the development teams at Dow Corning have done a good job of abstracting application elements, building up component libraries and reusing code, Gaus says. But it's generally easier and less expensive to build a new application using tried-and-true methods than to take an SOA approach. "To really consider what enterprise data is required for an application and what business processes are required, to build services around that data and those processes, then build an application on top of it, is going to be more expensive upfront than running off and building an application," Gaus says. To combat the temptation to do things the old way, he says, the company is considering a proposal to require staff to spend a percentage - around 5% - of their project budgets on SOA.

6. Budget realistically, or buy-in will suffer.

"People are hungry for information about how to budget for this stuff. The reality is, people don't understand the complexity of it, so they underestimate" cost, says Linthicum, who has devised guidelines for pricing SOA projects based on variables that include the number of data elements, the complexity of systems and processes, and new services needed. Typically, the time and labor associated with building an SOA - not the cost of purchasing technology - can surprise the uninitiated. Enterprises usually need help from consultants, and they need participation from internal staff skilled in architecture, security, data management, networks and application development. As for timing, Linthicum's rule of thumb is to allow about three or four months for each system an SOA project envelops; with normal complexity, a six-system project will take a couple of years from inception through funding, deployment and completion, he says. Adequate planning for time and labor is critical if you want to keep the business on your side. "The minute you underestimate that, people are going to lose faith in the project, because you're going to deliver stuff way over budget," he says.

7. Don't skimp on documentation.

You must have clearly documented policies and procedures for every aspect of the SOA development life cycle, says DaVita's Grant. Devoting the traditional 75% of effort to planning and documentation, and 25% to development makes things a lot more manageable, even though "everybody likes the 25% and nobody likes the 75%," he says.

8. Registries aren't a cure-all.

Documenting service attributes is a tricky part of an SOA, says Washington Group's Colton. "It has wound up being a lot more complex than I ever imagined," he says. One of Colton's ongoing projects is to find a way to keep track of both the technical details associated with services, such as translation requirements and service dependencies, and functional considerations, such as what processes are involved. Some commercial registries don't do justice to both types of information, and Colton doesn't want to rush into a premature technology purchase. "We developed a spreadsheet, for now, to understand all the pieces of information we need to track. Once we do that, we'll either build one internally or look at the commercial solutions to see if they address our needs," he says.

9. Don't forget the network.

SOA is going to add to the load on the network - it's that simple. Proper network design calls for modeling performance, which many enterprises fail to do adequately, Linthicum says. "You can model performance by looking at the behavior of a set of services. Now extend that 10,000 times. How many packets are going to be dispatched? How many packets are going to be received? The kind of bandwidth you have - is this going to bring your network to its knees? Sometimes it does," he warns.

10. Mind your techie talk.

SOA is a business endeavor, and it should be communicated that way. "Trying to get the IT language out of what we talk about, and get into the business language, is an ongoing issue," Washington Group's Colton says. "Nobody cares about how I do it," he says. "What they care about is what business processes I can address."

SOA in the enterprise A quick look at early adopters, their service-oriented architecture projects, and the tools making those possible
IT executiveProjectSOA tools

Rich Colton

Application integration manager, Washington Group International, Boise, Idaho
The engineering and construction firm is moving from a point-to-point integration model to a Web services-based model and standardizing on common business processes across business units.Oracle’s Fusion Middleware, including the BPEL [Business Process Execution Language] Process Manager, Developer 10g, and Web Services Manager.

Joseph Gaus

Enterprise architect, Dow Corning, Midland, Mich.
The specialty chemical company is building an SOA environment to improve asset reuse, create a more flexible IT foundation, and facilitate collaboration among its business partners, suppliers and customers. Existing services tap manufacturing and resource planning processes, including accounting, purchasing, demand management and supplier management.Systinet 2 platform from Mercury Interactive (which HP has acquired). Includes an SOA repository, policy manager and life-cycle management applications.

Bryan Grant

Lead application integration developer, DaVita, El Segundo, Calif.
The dialysis-services provider is using SOA technologies to integrate applications, handle mergers and acquisitions, and efficiently collect and publish information from multiple distributed sources.Sun’s Java Composite Application Platform Suite, including tools for business process modeling, services orchestration and development consistency.

Jorge Mercado

Lead architect, software architecture group, MedicAlert, Turlock, Calif.
The medical information provider is using SOA technologies to share data with partners securely and privately, eliminating unnecessary duplication and enabling new services, such as one that lets users store health information on a USB device.AmberPoint’s SOA Management System for run-time governance, including Web services performance-monitoring and error-handling; Microsoft BizTalk Server 2004 for process integration; Forum Systems’ Sentry for perimeter security and message validation.

< Previous story: How to avoid bumps on the road to grid computing | Next story: Best new career opportunity: Data center architect >

Learn more about this topic

The ESB: Driving the SOA into the enterprise

11/11/06

SOA governance: Preventing rogue services

06/26/06

AARP advances Web services

06/26/06

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Related:

Copyright © 2007 IDG Communications, Inc.

IT Salary Survey: The results are in