While an SOA can go far in addressing the important security, reliability and reusability of services, SOA is nonetheless a technical approach. Thus, the challenge of SOA - and the key to achieving business value - is elevating service enablement beyond just technology functions. The reality is that an SOA has limited value unless it encompasses disparate applications and platforms, moving beyond technology to be orchestrated and controlled in the context of business processes. SOA technology and methods provide a foundation for service enablement in an orderly fashion and allow an organization to avoid the pitfalls of deploying an uncontrolled maze of services.
But from the outset, organizations face the challenge of where to start. What services are going to add immediate value? And how are they going to be used by the most important business functions? Identifying the services that are consumed by the most critical business processes in an organization can be a daunting proposition.
That’s why enterprise architecture, business process analysis and business process management are integral to effective service orientation. SOA relies on the work of EA, BPA and BPM to define, analyze and execute resources where SOA has the best effect. The result is an agile enterprise in which business models drive executable business processes powered by a portfolio of services.
By focusing on the processes, activities, events, information and services that are required to execute the business, SOA gives business owners a more direct and active role in the design of IT systems that enable enterprise agility.
The Challenge to Formally Define the Enterprise
Although its concepts and technology are based upon decades of progress in IT, SOA requires additional work to free functionality locked up in legacy systems and to promote the culture of reuse required to make effective use of that freed functionality.
SOA starts at the enterprise level of scope. At this level, an enterprise needs to rationalize the goals, measures, etc. that direct progress toward its mission. It needs to profile its core capabilities and understand which capabilities are critical to achieve its goals and what enterprise artifacts provide the capabilities. This understanding is used to direct resources to implement SOA where the enterprise needs it most.
Below the strategic view, we have the definition of how the enterprise functions. This is where we find business processes, data and rules. At this level, SOA must empower business artifacts with system functionality. The objective is to express formally how the enterprise works in its own terminology and to enable the business professional to change processes, rules and the use of data. The professional essentially changes a model of the business to effect change in operational systems.
This requires balancing simplicity against control and control against IT resource integrity. The model of the enterprise needs to be familiar to each community. It must also contain enough detail to express the changes the enterprise needs to realize. Yet this model must enforce the real-world constraints of the supporting IT components. Each component consumes time, incurs cost and has limitations on availability and frequency of use. Changes in one business process cannot be allowed to impact other business processes inadvertently. Data integrity cannot be compromised. Security measures, audits, logging and other facets of the IT infrastructure must all be preserved. In other words, the challenge is to expose enough functionality to allow the business to retool safely without losing control over the underlying IT resources.
Exposing IT functionality under SOA involves publishing services and providing the means to execute the underlying components that realize each service. Defining services properly is no easy task. The notion of function is general enough to apply to almost anything. The enterprise needs to adopt formalisms for recognizing service functions so that 1) there is sufficient coverage to support business processes and 2) the service portfolio grows in a controlled fashion and holds only those services that are truly needed.
The other critical IT challenge is to unlock functionality already implemented in legacy systems. Most legacy systems were designed with specific user and system interfaces. They were not designed in the context of an overall service architecture and thus do not provide access to the functions they implement. For example, an order entry system may provide stellar validation, approval, scheduling and routing functionality, but other than the defined user and system interfaces, there is no way to employ these functions.
IT must change these legacy systems to provide a means to tap into functions, such as order scheduling. Once the function is delineated, IT can build an adapter that exposes the function as a service. The purpose of the adapter is to provide an interface to the outside world that conforms to the protocol all services follow. The adapter looks like a service to the outside world but delegates its implementation to the legacy function.
Modeling Manages Complexity
Once the enterprise level of scope is defined, CIOs and business executives use modeling to manage the complexity of an enterprise. Enterprise-wide visual modeling enables organizations to improve their performance and competitiveness.
Four significant capabilities within modeling solutions allow for superior SOA support:
- Preservation of the business analyst's viewpoint, retaining business terms and not requiring business users to understand the technical aspects of SOA.
- Methods for the technical user to configure execution-ready business activities so they directly translate into services.
- Autocompletion feature within a service-intelligent user interface.
- Delivery of real-time verification of execution-ready status.
As a result, modeling dramatically reduces the amount of time and interaction required to transform business processes into executable functions. Business engineers can take the execution-ready activities and, at the push a button, produce a BPEL-equivalent of the model that will reference the services that implement the process. This provides a preliminary design of the structure and services, allowing the designer to work through technical issues such as security, compensation of failures and logging. Modeling is vital to SOA because SOA involves abstraction - the removal of nonessential information to achieve a succinct, easy-to-manage model of reality. SOA, following the lead of model driven architecture, uses models to enhance understanding and to effect direct change. Three types of modeling are needed in SOA: strategic, business and technical.
