SIDBAR: The common sense SOA: Necessary components

A service-oriented architecture is only as good as the components and design standards that make it

If you want a practical and usable SOA - not just a bucket of services - then you should pay attention to five aspects of SOA development, say integration experts. The following bits of advice were gleaned from Ron Schmelzer, an analyst at ZapThink LLC; Steve Craggs, president of Saint Consulting; and Jamey Harvey, deputy CTO for the District of Columbia.

Open standards. SOAs don't have to be based on open standards, but they won't be as useful in a cross-platform environment if they aren't. Adhering to standards such as Web Services Description Language (WSDL), XML and WS-Security ensures that the SOA will be adaptable to all enterprise systems.

Granularity. How you splice application functions into Web services is a key consideration. If too many single-function services are needed to execute a process, the performance slows. Likewise, a bloated service that contains the entire process becomes too specific to use in other applications. The most practical approach is to create a balanced collection of smaller, reusable services for common functions and larger ones for one-off processes.

Service contracts. WSDL is the standard specification for creating a Web services contract, or a description of things such as the format and endpoint for a service. A well-defined service contract will result in more reusable services.

Enterprise Service Bus. An ESB provides a backbone for publishing services and enabling applications to access them. It also typically has useful features such as adapters for legacy systems, services-orchestration capabilities, security authorization and authentication, data transformation, support for business rules and the ability to monitor for service-level agreements.

Other integration tools. Not all integration should be done with Web services. EAI (for integrating application transactions), EII (a sort of middleware data query engine) and ETL (for moving data into a data warehouse or database) all have their place. They can also all be linked to an ESB via Web services.

So there's no benefit to trying to turn everything into a Web service. "An SOA itself is only a tool in the belt of the enterprise architect," says Schmelzer. "It's good for dealing with change, for handling heterogeneity. But it's not good for building tightly coupled systems."

SIDEBAR: Protecting Programmers

Seven tips for keeping developers focused on what they do best

1. Set up gatekeepers, such as project managers, between developers and the rest of the organization.

2. Don't use developers for ancillary project work such as technical documentation. Their strong suit is development.

3. Set up expectations upfront with business sponsors.

4. Recognize that programmers may get derailed from development efforts as a result of unforeseen events, such as a maintenance problem for another system they previously developed.

5. Find and implement automation tools to help developers with additional regulatory and security requirements.

6. Gradually phase in new project management life cycle and quality assurance methodologies, recognizing the amount of time it takes for your organization to accept change.

7. Ask programmers how project management methodologies might stifle development.