Service Oriented Architecture (SOA) refers to an architectural solution that creates an environment in which services, service consumers, and service producers co-exist yet have no dependence on each other. SOA enables an enterprise to increase the loose coupling and the reuse of frequently used software assets. These software assets together with the functionality that they provide are called services in SOA terminology. By nature SOAs are typically applied to solutions with highly volatile requirements.

In this article the emphasis will be on how to apply service orientation to solve a problem at the enterprise level and how to decide how much service orientation is "optimal." The word optimal means the point of maximum pay-off for the investment specified and implies that once that optimal point is crossed either the return on investment tends to drop or the return doesn't grow proportionate to the investment.

Here we'll attempt to indicate some key points that can be used in making decisions about how much service orientation is optimal.

SOA Solution Overview
An SOA solution refers to a solution built using SOA concepts and to realize a SOA solution it's necessary to map the architecture to an implementation using a specific set of technologies/products/platforms. As with any other solution, a SOA solution is characterized by a set of mandatory (and optional) components. (See Figure 1 for the main components of an SOA solution.)

A complete SOA solution consists of these main components:

• Producer: A producer is an entity that offers a specific service or functionality. A producer usually registers the functionality that it provides and the interface that has to be invoked to make use of the service in the repository.
• Consumer: A consumer is the entity that makes use of the service offered by the producer. A consumer looks up the repository and identifies the details about the service including the interface. It then invokes the service using the appropriate invocation mechanism.
• Service: A service is the entity that does a specific task when invoked. It always does the same task regardless of how it's invoked. It's provided either by a business process or a set of business activities realized using a programming language.
• Contract: A contract or an interface specifies the format in which the data is provided to the service to do a specific task. It also identifies the invocation mechanism to invoke the service.
• Repository: A repository is a glorified version of the registry and includes the metadata relevant to the solution, namely the service, service contract, data/object model, and so on. A repository stores the details about every service that can be invoked and the details about how to invoke it which includes the interface details, invocation mechanism, and so on.

Problem Description
SOA is making big strides into every company and penetrating into every business in some way or the other. While the analyst forums are focused on evolving the benefits of SOA from a business perspective, standards bodies are involved in evolving the standards needed by SOA to build an open architecture that standardizes SOA solutions across all industries. This has resulted in every company being pushed to "assimilate" SOA in its "blood" and use SOA as a universal phenomenon. In other words, every company takes pride in using SOA in every communication, every newsletter, every project, and so on without making a conscious decision about how much is "enough." This situation can lead to a company over-investing and diluting the SOA concept. It can potentially impact both the company and the SOA. As a result, it's very likely that the company might "burn through" its finances or attribute its failure to SOA. So it's necessary to understand how much SOA is optimal and decide where SOA should and shouldn't be used.

SOA Impact Zones
SOA typically covers all aspects of an enterprise when applied in full. Though it's likely that every company may not have reached the maturity of applying SOA to all its departments, our focus is on the Service Oriented Enterprises (SOEs) that use SOA broadly. Some of the key impact zones include the following:

1.  Program Governance and Management Zone
An enterprise's program management and governance groups are definitely impacted. In this context, it's good to understand what the functions of these groups are. Key functions include providing a strong rules base for the SOA program and support in terms of defining the hierarchy of management staff, their roles, responsibilities, interactions with other management staff, and so on. In this context, it's necessary to use certain management models (like patterns in the software industry) to define the functionality clearly. The tendency is to have a "fully" automated governance system in place (typically called e-governance) that can address and support SOA's deployment in the enterprise.

The following points help identify the level of automation required while working out a governance body for an enterprise:

• The size of the enterprise. How big is the organization? This is a key question to be posed before working out a huge governance program. If SOA coverage is small (say, less than 20 people) then it makes sense to have manual processes. It's widely believed that automation only makes sense in huge organizations since automation requires a huge investment.
• The number of SOA deployments. How many SOA deployments will the program governance cover? If there are only few projects (say less than five) then it probably makes sense to use manual processes.
• Future plans and forecasting for SOA growth. What is the projection for future SOA growth and expansion? This is another important point to keep in mind while deciding on the SOA governance panel. However, remember that projections don't necessarily materialize and even if the future seems bright, it's better to make provision for additional growth in the governance panel and processes, but not necessarily invest in it.

2.  Architecture Zone
The architecture zone implies all the aspects of the technical architecture that's part of the SOA solution. This includes the various views of the architecture itself like the business view, technical view, implementation view, functional view, support view, and so on. These views help define a complete system that can support SOA. This zone can be classified into the following sub-zones:

Providers
Providers are the assets that provide a specific functionality. It's necessary to decide how much provider functionality has to be automated. As we would all agree, every enterprise should have an evolution scheme that would initially start with a manual set of processes, technology, and solutions that would graduate into a semi-manual (partially automated) set of processes, technology, and solutions. It's only with repetitive use - and against specific requirements - that a company should consider automation. It may be perfectly fine to leave specific functionality as a manual task. For example, in the case of mobile operators, it might be okay to automate only the provisioning processes, but leave the rollback processes as manual tasks for the operator to do. The amount of investment required to automate these rollback processes wouldn't result in a proportionate pay-off.

Some tips include:

How much provider functionality is going to be reused externally and so externally published? For example, while building an inventory modeling application, we might want to expose only the coarse-grained provider functions like create_a_dsl_model_in_inventory and decide to keep all the internal atomic functions used to create the model as internal (like the create_a_dsl_equipment, create_a_port, enable_a_port and so on). With this step, it's possible to "balance" the number of interfaces/services exposed outside and those that have to be internal.

How much provider functionality is internal but used in other applications and so has to be internally published? In this case, the internal functions are aggregated and in aggregating them we would have to invoke the internal functions. When doing this, we might want to create internal or locally shared functionality and make it available to other internal functions or applications.

How much of provider functionality won't be reused or is legacy and so doesn't require loose coupling resulting in direct interface invocation? To understand this point, it's necessary to know how much of the provider functionality is being developed from scratch and how much is being reused from other applications (which are legacy). Legacy functionality isn't typically attempted for further break-up since it takes more time and effort to re-engineer, and re-engineering doesn't guarantee the same behavior and performance. So, it might be necessary to "wrap" the legacy functionality with a SOA-based provider and expose only the final aggregated functionality to the outside world. The other provider functionality doesn't have to be loosely coupled and, in fact, can remain monolithic.

How much provider functionality really requires automation? A critical decision in building a SOA system is to decide how much automation is "required" or "enough." For example, consider a network provisioning scenario needing a software component that has to configure specific hardware (probably routers) and enable certain ports so the traffic flows. In this scenario, it's possible to develop business processes or write code (using a language like Java) that can establish the session with the hardware, talk to the hardware, provision the customer/service, and configure the hardware. While doing this, one of the steps might fail and require a rollback. The rollback policy would decide how the rollback should be done. The rollback policy would specify at what points in the process the rollback would be done (rollback gates) and what the rollback granularity is (for example, do all the steps have to be rolled back or only a few selected block of steps). In this case, it's possible to develop the rollback components in the business process, however, they tend to be overly complex and require a lot of effort (relative to the effort spent in developing the process itself), since the processes have to check the context in which the failure occurred and try to restore the original context. So, it makes more sense to notify the operator when a failure has occurred and provide manual intervention to fix the problem and leave the rollback path completely manual.

How much provider functionality can be or has to be manual depending on either the pay-off or difficulty of automation? The essential lesson is that automation isn't a panacea for every problem. While automation can provide added support to increase productivity when used with due diligence, it can be overkill in scenarios that require logic and reasoning and span multiple subsystems. For example, it might be very hard, if not impossible, to develop a rollback process when multiple subsystems are involved, since the process has to check and roll back the states of each of the products involved. This assumes that each and every subsystem do the same.

Consumers
Every consumer in a SOA context doesn't have to be an automated program or a business process. The consumer for a specific service can be a human operator who would run a specific tool and invoke the service manually. Some of the key decision points in this context are as follows:

• How much consumer functionality needs externally offered functionality? And how many of these external functions could change (either of the service contract or interface contract) and require a registry lookup? How much of the consumer functionality requires external (B2B) interfacing? The consumer functionality that doesn't require a registry lookup doesn't have to be very flexible. In other words, it can choose "tight coupling" resulting in better performance.
• How much of consumer functionality requires internal functionality, but is used in other applications and so has to be internally published?
• How much of consumer functionality isn't going to be reused or is legacy and doesn't require loose coupling, resulting in direct interface invocation?
• How much consumer functionality really requires automation?
• How much consumer functionality can be or has to be manual depending on either pay-off or the difficulty of automation?