Putting the A in SOA

Computerworld - Service-oriented architecture (SOA) is generating a big buzz. Although most of those doing the buzzing understand the benefits that an SOA offers, few understand what it takes to realize these benefits.

As was the case with large, widely hyped technology initiatives of the past, everyone seems to know that they need an SOA, but they are not necessarily clear on why, or how to get it. But unlike many hot IT topics of the past, SOAs truly deliver clear bottom-line business results.

An SOA allows organizations to build applications from services that live in the network. These services are self-contained: they are independent of the context or state of the other services and they work within distributed-systems architectures. This architecture dramatically reduces the functional complexity of enterprise software systems, while at the same time increasing development flexibility. It allows companies to rapidly adapt their IT infrastructure and compose and recompose business processes to meet ever-changing business needs and increase overall business agility.

Unfortunately, many SOA initiatives fail to realize these benefits because they lack strong management of the architecture from the very beginning. The architecture is too often missing from the service-oriented architecture.

To attain the agile, cost-effective IT infrastructure SOA provides, organizations need development and management environments that are supported by governance mechanisms. The traditional approach to application creation does not work in an SOA. Allowing siloed groups of engineers to do their own thing in isolation is a recipe for disaster. Unless the migration to SOA is effectively managed, organizations will get increased costs and more complexity in the IT environment -- exactly the opposite of what they hoped to achieve.

Any IT executive who wants to succeed with SOA should ensure that the following four practices are in place:

• Design, deploy and manage the architecture. Failure to implement an SOA without an adequate focus on architecture results in an architecture that is largely crippled, rather than loosely coupled. SOA is a moving target -- the architecture is never finished. Having a target architecture is vital.
• Ensure that development adheres to the architecture. Far too often, the architecture lives in inert PowerPoint or Word documents that are rarely read. IT management and development project leads must establish governance practices and systems that require project teams to follow the architecture, adhere to standards and ensure that services are in compliance with the SOA.
• Manage XML schemas. Early control of the XSD files that represent corporate data is critical. After the SOA achieves a certain level of complexity, XSDs become nearly impossible to untangle. Client/server projects faced much the same problem because IT departments failed to control database schemas from the beginning.
• Establish a central repository for SOA: It is impossible to have a well-managed SOA without a central registry/repository. The repository should discover and promote services for reuse, map relationships among various assets for impact analysis and track and measure the value of the SOA. Without this repository, Web services and other applications built on the SOA often end up being developed in isolation and misaligned with architecture. The end result: increased complexity and costs.