The value of service-oriented architecture (SOA) is the concept of agility, or the ability to limit risk by managing change. Today, many enterprises are fighting to make this a reality, yet few approach SOA using the right methodologies and technology, and most have yet to define the real value of SOA and agility.

Truth-be-told, the core notion of SOA is not that complex. In essence, you're looking to identify and define points in your enterprise systems that will be services, information, or processes. From there you define your existing resources, and define the new resources required along the way.

However, the core value of SOA isn't to turn everything into services, but the ability to leverage those services to solve business problems quickly. Or, the ability to define and redefine business solutions as the needs of the business evolve or rapidly change. How you approach the creation of this architectural domain is key to the success of your SOA.

In this article we'll strive to understand the basic approaches to SOA, and how to define and select the process configuration or "orchestration" technology in the context of your SOA, as well as define the value. We'll look at the basic procedures for understanding your own assets, how to define new assets, and how all of this links into a process configuration layer.

Core to this concept is the use of technology that lets you configure and reconfigure these processes as the business requires. In essence, you'll drive change through a powerful layer of technology that can abstract all related services and information. These layers hold the promise of SOA, and this is where SOA provides the greatest return on investment (ROI).

It's About Agility Through Configuration
What's core to the value of SOA is the ability to place things that will change over time into a configuration layer, making it easier for key business processes to change. For instance, the addition of a new product line causes the way the company defines sales tax to change. Using SOA, we can make that change as a configuration to a process, or process configuration, and not force redevelopment of enterprise systems. Thus, the core notion here is about putting things that will or may change over time into the process configuration layer, and address things that will probably not change as services. This means that the architecture is better able to support change, and thus brings the value of agility to IT.

While SOA was initially sold around the value of reuse, users have come to discover the real value that SOA provides is the ability to change core business processes without requiring waves of redevelopment, testing, and deployment (see Figure 1).

Indeed, agility has proven more valuable than reuse when considering the value of SOA. In a recent study published in Information Week, entitled "InformationWeek Analytics: State Of SOA," it was found that that the value of reuse is only marginal:

"The percentage of overall software reuse within organizations was only marginally higher after initiating SOA, with a 32% reuse rate cited before the SOA project versus 39% after."

Thus, the value proposition around SOA is the ability to promote an agile architecture, or an architecture that is built to change. If we keep this objective in focus, the business value will become apparent, considering the value of accommodating the needs of the business in a much more timely manner.

As we define our architecture, we define the data abstraction, data services, and transactional services as largely static. This means that they typically won't change much over time, and services can be added or deleted from the architecture as needed.

In contrast, the process configuration, or orchestration, layer is able to connect with data services and transactional services, exposed from many different business systems in the enterprise, and create processes using process configuration tools, such as ActiveVOS, which can abstract these services into a configuration layer where they can be easily and visually bound to processes that provide sequencing and logic control to define the higher-level business processes (see Figure 2).

The power of this paradigm isn't around the act of defining these processes, but the act of redefining or changing these processes as the needs of the business change over time. In essence, providing a master control mechanism over the core business processes that are able to leverage the power of all connected enterprise systems via services, and thus bring the power of agility to SOA and to the enterprise.

Considering the value of agility and process configuration as core tenants of SOA, it's a good exercise to determine the value of agility for your business or project. This lets you better define your own needs, make a business case for the SOA project, and set the appropriate expectations.

What's the value of all this? What's the value of agility? Agility is a strategic advantage that's difficult to measure in hard dollars, but not impossible. We first need to determine a few things about the business, including:

• The degree of change over time.
• The ability to adapt to change.
• Relative value of change.

The degree of change over time is really the number of times over a particular period that the business reinvents itself to adapt to a market. Thus, while a paper production company may only have a degree of change of 5% over a five-year period, a high-technology company may have 80% change over the same period of time. Thus, agility has value, but different value based on what the business is and does.

The ability to adapt to change is a number that states the company's ability to react to the need for change over time. The notion is that the use of a process configuration solution would let you make many changes to the core business processes, typically without driving change to the underlying services and data.

Finally, the relative value of change is the amount of money made as a direct result of changing the business. For instance, a retail organization's ability to establish a frequent buyer program to react to changing market expectations and the resulting increases in revenue from making that change.

Approaching SOA
When approaching SOA you need to consider that we aren't looking to replace systems, just leverage them in different ways to provide IT with the power to change core business processes, at will, when needed, and without a significant impact to cost. In essence, breaking the systems down to their functional primitives, including data and behavior, and building them up again as sets of services that can be further abstracted into process configuration layers that provide the configuration capabilities letting IT adjust the IT resources when needed to accommodate the changing needs of the business. While this may seem complex and invasive, with a bit of planning and the right technology the process of defining and building a SOA isn't that complex, expensive, or risky.

You need to consider doing the following:

• Define Application Semantics
• Define Services
• Define Processes

Define application semantics refers to the act of understanding and documenting all information in the problem domain, and what that information means to the business. You must understand the metadata and define the relationships between the data, as well as ownership, security, rules, logic, and policies that may be around the data.

Having a complete semantic understanding of the problem domain means that you have a solid starting point for defining your SOA. From there you can create an abstract representation of the data that may better meet the needs of the business, putting the data in a better logical virtual schema that can be further abstracted into data services (see Figure 3).

Define services refers to the act of defining the existing and required service behaviors needed for the target architecture. This step is about looking at all system behavior and then determining which behaviors should be exposed as services, or perhaps created. The concept here is to define as many points as needed as services and do so at a level of granularity that makes sense for the architecture. Keep in mind that services, both data services and transactional services, will become the core interfaces into the architecture, and thus need both governance and security systems in place to manage these services over time.

Define processes refers to the process of defining and listing all business processes that exist in your process configuration domain (see Figure 4). This is important because now that we know which services and information sources are available we must define higher-level mechanisms for interaction, including all high-level, mid-level, and low-level processes. In many instance, these processes have yet to be automated or are only partially automated.

The purpose of understanding the processes in the business around the notion of SOA is that the processes are things that will likely change over time, where the services likely won't change. That's a good test to see which behaviors should exist in the domain of a process, and which should exist as services. Keep in mind that processes, typically, can also be exposed as services from the process configuration engine. This provides you with an additional architectural advantage since you can consider processes something that binds services together to solve a business problem, or they can become services unto themselves.

Implementing Process Configuration
Since we're focused on the orchestration (process configuration) layer here, let's drill down on the core issues around implementation. They are:

• Understanding the Use of Standards
• Business Process Management
• Implementing Process Configuration

We leverage standards with our process configuration layers to reduce risk and leverage best practices. In essence, this is the ability to provide a base of understanding using well-defined and standard approaches.

BPEL (Business Process Execution Language) provides a standard language for creating executable and abstract business processes that extend the Web Services interaction model and enables it to support business transactions. The core notion of BPEL is to define an interoperable integration model that facilitates the expansion of automated process integration in the context of SOA. Moreover, BPEL provides a standards-based modeler for BPM, and thus a common language for defining and deploying processes. Products such as ActiveVOS can make using BPEL by humans more manageable, using visual design elements that are both intuitive and pragmatic.

The idea is that the process configuration tool supports a standard, such as BPEL, and the process designer or SOA architect implements that standard in the tool, such as ActiveVOS. In essence, the standard defines the "how," and the process configuration tool, such as ActiveVOS, defines the "what, where, and when."

The best definition of Business Process Management can be found in Wikipedia:

"Business process management is a field of management focused on aligning organizations with the wants and needs of clients. It is a holistic management approach that promotes business effectiveness and efficiency while striving for innovation, flexibility and integration with technology. Business process management attempts to continuously improve processes. It could therefore be described as a ‘process optimization process.'"

What's relevant in the world of SOA is that the core principles of Business Process Management are leveraged in the context of creating a technical architecture, and in a process configuration layer and enabling technology. In essence, this couples the value of Business Process Management with a core technology architecture such as SOA. So those who put the SOA together should consider the core principles and methods of Business Process Management when creating the process configuration layer for their SOA. This will bind an effective approach to process management conceptually, with an effective approach to process management technically.

ActiveVOS, for example, provides a process configuration development and execution engine that allows enterprises and developers to automate business processes, collaborate across IT and business boundaries, control the overall state of the business, and adapt rapidly and easily to change. ActiveVOS supports the latest versions of BPEL, BPMN, and the BPEL4People specifications, which allow human activities to be included in business processes. The use of ActiveVOS provides those who create SOA with the value and ability to change core business processes, as needed, without significant or really any cost. You simply make the changes at the configuration layer, and no additional development, redeployment, or testing is required. With ActiveVOS you can model, simulate, develop, test, deploy, and manage sophisticated process orchestrations in a visual designer that creates executable processes.

Products such as ActiveVOS allow those who build a SOA to model business processes visually and then transform them automatically to BPEL for execution. Those designing and deploying processes can leverage the visual aspects of the tool, removing the designer from having to code, or the designer may work from the code as well. Thus, the designer can work at his or her comfort level, making the process of creating or changing processes quick and easy.

Besides process configuration and execution, ActiveVOS also provides a dashboard and a universal console with system management capability, including the ability to manage the entire system with dashboards, integrated reports, and a universal console. Also included is enhanced problem determination with "time machine" and "process rewind" capabilities to discover problems in faulted processes.

Call to Action
It's unfair to think that SOA is complex and expensive. If you approach SOA with the right expectations and right procedures, the end state should actually result in a significant reduction in operating costs, better efficiencies around core business system processing, and the value realization of agility in your enterprise, or the power to change core business processes as the needs of the business change over time.

However, this doesn't happen automatically so you need to take action to ensure that your IT infrastructure and core business systems are optimized for your business requirements. Now is the time to take action and determine the health of your underlying enterprise architecture and determine a path to have IT provide more value. We suggest the following:

1. Understand the cost of lack of agility when considering your core IT systems.
2. Determine the ROI from leveraging SOA approaches including the use of process configuration technology.
3. Understand all core IT assets in the problem domain including data, services, and processes and how they're abstracted in a process configuration environment.
4. Define your architecture as an "as is" and "to be" state.
5. Create the final execution plan and drive the change.
6. Access the value of the change, including the value of process configuration.

There are no magic bullets here. It's really a matter of determining your core business issues and creating an architecture that not only supports the business today, but can quickly change as the business needs change. While we've been good at creating an instance of enterprise architecture that works for the business during an instance in time, any shift in the business means that the architecture is quickly out-of-line with the business. We have to make sure that IT can keep up and provide value to the business.