The hands-on work for IT begins during the phase of mapping processes to services. This requires understanding those processes from a business view, requiring a true business-IT partnership. IT can’t just work on requirements thrown over the wall; developers must understand what the actual business goals and benefits are to understand what to deliver.

There are several dangers in mapping processes to services: defining them just for the current project’s needs, defining them at the wrong level of granularity, and building services that aren’t needed.

Developers have to anticipate how the service — whether created from scratch or derived from a legacy application — might be used in other processes, so the service can be employed in both current and future projects. Typically, an architectural team can provide guidance here, based on an enterprise blueprint against which they can see and predict similar needs elsewhere.

Blunders often occur in developing services at the proper level of granularity. The more functions a service performs, for example, the less likely it can be used (in its entirety, at least) in other processes. But developing services that are singletons results in a hoard of services that are hard to compose into applications or that have so much interprocess communication that performance is unacceptably slow. It takes experience to figure out the right balance — to build molecules, not atoms or compounds.

But enterprises should also anticipate that they will end up with multiple levels of granularity, notes Tata’s Mohanty — the right level varies from service to service based on what specific functions are likely to be reused. For example, an authentication service may be fairly fine-grained, while a credit-check service may be fairly coarse-grained.

Enthusiasm for SOA can lead to efforts to turn everything into services. That just wastes development effort and can complicate later projects. SOA is meant for environments where processes change frequently, so the ability to share a common service and then replace it with a new version quickly updates multiple processes at once with the new approach. But many functions are static or slow to evolve, and play little with anyone in other areas of the organization. Leave them aside and focus on higher-priority tasks.

Back to intro | Next: Timing the technology choice