Tips for designing a service-oriented architecture

The realities of project deadlines, team skills, and tight budgets mean that building a Web services SOA (service-oriented architecture) is less about choosing a technology than it is about spotting opportunities for maximum return on software investment. Here are some core design principles to help you concoct a plan that will pay off soon and, with luck, over the long haul.

Start small.To gain experience and early wins, begin by “wrapping” existing interfaces with SOAP and WSDL to achieve one-way, point-to-point integration. These first Web services should mimic current, data-centric APIs. Core, stable applications running on legacy systems or established, well-defined trading partner applications are good candidates.

Read the road map.Don’t let the relative ease of implementing Web services integration obscure the architectural vision. Plan for three stages of sophistication and maturity: 1) read-only, data-centric services that mimic existing APIs; 2) two-way, transactional models that leverage emerging standards and product capabilities; and 3) asynchronous, document-centric models that reflect the business process focus of service-oriented design.

Let the business process lead.In each stage of SOA maturity, take a “business service” perspective. Design each Web service as a coarsely grained, discrete task with business process inputs and outputs before specifying data types or APIs. The SOAP interface and its WSDL descriptor should reflect this same process-centric approach, not the minutiae that many programming tools auto-generate.

Target high maintenance costs.Look for manual processes hidden in distributed functions such as field sales or customer support. Applications with high costs of integration and management are good candidates for strategic investment in service-oriented design. Target systems that require specialized skills to operate and develop, that demand dedicated hardware to function, or that need specially licensed add-ons and adapters for interoperability.

Identify your core services platform.Most companies will start with work they’ve already done on J2EE or Windows servers. Others may want to choose another core Web services platform. For example, SAP is slowly integrating Web services standards into its BAPI (Business API); companies that rely heavily on SAP software may wish to wrap BAPI applications in SOAP and WSDL and go with SAP’s definitions of common business documents. Whatever you choose as your core platform, make sure the vendor embraces independent standards and can prove solid interoperability. Membership in the WS-I standards organization is a good sign.

Build shared infrastructure services.An SOA composed of heterogeneous systems must draw on its own special set of services to ensure everything is reliable, manageable, and secure. Web services management products help address these needs by providing functions such as version control and QoS, but other core needs such as authentication likely will be assembled from existing infrastructure such as identity management systems. Basic application utilities such as logging and data transformation are also good candidates for shared services.

Finally, remember that the perfect is the enemy of the good. In IT, too many projects ultimately fail because managers refuse to make practical compromises or harbor religious convictions about one architectural vision or another. Don’t let the evolving set of Web services standards for security or complex transactions scare you from starting work. In many ways, pragmatism defines the philosophical core of SOA. Web services standards and software solutions will continue to mature. But the goal of service-oriented computing is feasible today.