Sometimes the old clichés are the best ones. I've been working with a number of different groups and companies recently, defining and refining their takes on service-oriented architecture and Web services. In thinking about the different perspectives necessary for a full understanding of how to use Web services, SOA, and business process to achieve business agility, I was struck by phrases like "forest for the trees" and "50,000-foot view." As usual, what you think about Web services and how to use them depends on what you do and how it affects your day-to-day work.

Software architecture, by which I mean the design of software systems according to patterns, best practices, and business conditions, can look wildly different depending on your role in the process. An architect charged with building a stand-alone application may make decisions that an architect building an enterprise infrastructure may think are ludicrous - and they may be, at the "50,000-foot level."

Look at the management of identities, for example. For a stand-alone application, this may be as simple as a logon ID and password combination maintained in a database table. That may be perfectly reasonable for the application architect, based on requirements.

However then the enterprise architect steps in. Charged with achieving high levels of integration and reducing costs, the enterprise architect typically would look for a shared service model that will allow common routines and functions, such as security, to be defined and managed once.

Here we have the classic conflict - Application versus Service, mainly because I described the "traditional" role of the application architect, which is to design stand-alone applications.

In a world where every new system needs an ROI justification and staff never increases along with work, SOA is an answer organizations are turning to for productivity enhancements. But in order for SOA to assist in this fashion, perspectives have to be adjusted throughout the chain of command.

One of the biggest changes is the move from building to assembling applications. Developers no longer build applications, they build services. These services are assembled using business process management to form business processes. The application builder now provides an interface for interaction with business processes by assembling services and processes as needed to complete the particular task.

The job of the SOA enterprise architect is to design and designate all of the services necessary to support the business processes. Part of this job entails understanding the various specifications for Web services that are available and deciding how to use them (or even whether to use them) to support activities across the board. In the case of security, it might mean selection of a security management system and the use of SAML, XACML, and other standards. Then these standards have to be designed for appropriate usage, such as determining what level of security is required for each service.

The question of achieving business agility from SOA is similar to that need for perspective between the application/service designer and the overall enterprise architect. An SOA enables integration and solves a number of long-standing but primarily technical issues (such as getting J2EE and .NET to talk meaningfully), but it doesn't completely address the needs of the business when it comes to being adept and open to change.

Business process management allows an organization to take a set of services and create business processes. A business process is a task (which may be complex and involve multiple touch points and interactions) assigned to one or more individuals and accomplished via software.

However to accomplish the goal of achieving business agility, we need another perspective - the business perspective. The ultimate goal of an SOA is to provide the business community with software that enables the agile enterprise and allows the business to make the changes it needs to cope with changing market conditions and regulatory issues.

Are we there yet? It's all a matter of perspective.