By Paul C. Brown

Are you worried about getting a business return on your service-oriented architecture (SOA) investment? Are you a business manager who has been disappointed by an IT project, or an IT manager or architect who has been disappointed by the business’s reaction to your project?

If you’ve been part of one of these disappointing projects, most likely the reason for your disappointment was a disconnect between the business and IT communities – a disconnect that resulted in the project failing to deliver the business value that both sides expected. It is likely that this disconnect was not even recognized until late in the project. So late that a lot of concrete had been poured over the misunderstandings and misconceptions. So late that correcting these misunderstandings and misconceptions began to look like another project.

Such disconnects are simply intolerable in service-oriented architectures. Obtaining a solid return on a SOA investment requires more than simply avoiding such disconnects. It demands proactive and constructive communications between the business and IT communities.

The business must clearly define the business objectives of the SOA initiative – the things that will provide the actual business return on the SOA investment. The business and IT community must then join forces and work together to achieve these objectives. Together, they must define the business process and system changes that are required to produce the expected business results.

This collaboration is not just to make SOA initiatives succeed. It is essential for any project that is supposed to produce business value. For the most part, failed projects are projects that have either lost sight of the business objectives or failed to focus the business process and system changes on achieving those objectives.

The challenge here is that business processes and information systems have become so completely intertwined that it is literally impossible to make changes to one without altering the other. In particular, changes to information systems alter business processes – often in unexpected and undesirable ways. Despite this, our projects rarely stop to actually consider the design of our business processes unless we happen to be tackling a major business process reengineering effort. As a result, our business processes just sort of evolve, piecemeal, project by project, as we make changes to our information systems.

Service-oriented architectures are supposed to bring an end to this chaos. SOA is supposed to provide us with clean, well-defined interfaces between business entities – between service providers and service consumers. But who, exactly, are those service providers and service consumers? Are they systems? Well, yes – and no. There are, indeed, systems providing and consuming services.

However, those systems are providing functionality on behalf of business units for use by other business units. Thus, when we define business services, we are actually defining the boundaries between business units and the interfaces between them. In other words, we are defining the structure and organization – the very architecture – of our business units. The architecture of business units is not a technical issue – it is a business issue. SOA determines the architecture of both business units and systems! Consequently, both business and IT need to work together to successfully implement SOA.