One of the biggest barriers to SOA adoption is fear of not meeting the high demands of the runtime environment coupled with the need to provide business agility. As more layers have been introduced by the components of the new technology stacks, the points of failure in distributed application have multiplied. While the IT side of the house is very enthusiastic about the plethora of features provided by technologies typically associated with the SOA stack - object-orientation, process orchestration, Web services, business rules, and so on - the business side of the house is usually hesitant to invest substantially in new territories that may lead to high risk for existing businesses. Service orientation promises to bring business agility, but will it continue to sustain the demands of operating the business? In the requirements phase of SOA, the former is associated with functional requirements and the latter with nonfunctional requirements.

Adoption of SOA holds the promise of enabling businesses to more effectively adapt to change - and to add new offerings to their existing products in a more effective fashion. These offerings are implemented on the technology stack as functional requirements. The other side of the equation that allows service enablement to actually achieve realization is the satisfaction of the nonfunctional requirements - requirements that address aspects of the system that do not directly affect the business functionality. Instead they address aspects of the architecture that are essential for the successful operation of the system and its acceptance by the end users as well as the operations and maintenance staff. The satisfaction of nonfunctional requirements is what determines the success or failure of the system when the rubber meets the road.

Clear expression of nonfunctional requirements by business and their successful implementation by IT is crucial for any project that is undertaking service enablement. After all, the main goal of SOA is to bridge the business-IT divide by leading to the establishment of an agile organization. The nonfunctional requirements for a service-oriented architecture address several aspects of the architecture, including the ability to meet the service levels of the business (Service Level Agreements), the ability to maximally leverage the ever-changing technology stack, the ability to perform to RAS (Reliability, Availability, and Scalability) specifications at runtime, the ability to satisfy the needs of effective life-cycle management and maintenance, and the ability to effectively adapt to change (leading to business ability).

The expression and realization of nonfunctional requirements is a challenge because while the system can be built to functional specifications, the expression of many of the nonfunctional specifications is not possible in a very precise manner. For example, during the early stages of the architecture design, it may be possible to identify security requirements, but hard to express what constitutes a system failure in the case of a security breach. And at runtime, how can the millions of lines of logs be interpreted to determine whether security thresholds have been crossed? Capacity planning is another example. Systems that are built to satisfy a certain performance criteria are expected to scale to higher volumes in a certain amount of time. How much buffer should be built in to pad the business requirements to make sure that the requirements expressed on paper are actually the ones that will need to be satisfied six months from now?

Fortunately SOA does, to some extent, provide more formal means of expressing, implementing, and monitoring nonfunctional requirements. It is only with the advent of SOA that SLAs have come to mean the same thing to a business user and to an IT specialist. This is probably the main reason why there is so much excitement around the concept surrounding the "Same Old Architecture."

Good sources of information on addressing aspects of SOA such as those discussed in this article are hard to find. I recently read a text, Service-Oriented Architecture Compass by IBM press, which covers some of these aspects in a concise fashion, while at the same time addressing the strategy to transition to SOA. If you are interested in this area, you may want to pick up a copy.