The decomposition of business applications into services is not just an abstract process; it has very real practical implications. Services might be low-level or complex high-level (fine-grained or coarse-grained) functions, and there are very real trade-offs in terms of performance, flexibility, maintainability, and re-use, based on their definition. This process of defining services is normally accomplished within a larger scope — that of the Application Framework. This is the actual work that must be done; that is, the development of a component-based Application Framework, wherein the services are defined as a set of reusable components that can in turn be used to build new applications or integrate existing software assets.

	express delivery
	• print  • comment
	Organizations that focus their development effort around the creation of services, using existing technologies, combined with the component-based approach to software development will realize several benefits. This article is excerpted from "Migrating to a service-oriented architecture", part two in a series of white papers intend to help plan migration to SOA. The authors are Kishore Channabasavaiah, executive architect, IBM Global Services; Kerrie Holley, distinguished engineer and chief architect, eBusiness Integration Solutions, IBM Global Services; and Edward M Tuggle Jr, senior software engineer, IBM Software Group.
	Glossary terms: SOA, componentization, granularity, business process, on demand, lookup tool Sponsored links: your text link here

Many IT architects choose to implement within an existing framework; the process of decomposing the existing applications into components for the framework is work enough, without reinventing all the other general-purpose and system components known to be needed. However you approach it, you can implement the architecture using technologies and frameworks that exist today, and so you come full circle, back to the beginning, where the process starts with an analysis of the business problems that must be solved.

Benefits of deploying SOA

A service oriented architecture (SOA) can be evolved based on existing system investments rather than requiring a full-scale system rewrite. Organizations that focus their development effort around the creation of services, using existing technologies, combined with the component-based approach to software development will realize several benefits:

• Leverage existing assets — This was the first, and most important, of the requirements. A business service can be constructed as an aggregation of existing components, using a suitable SOA framework and made available to the enterprise. Using this new service only requires knowing its interface and name. The service's internals are hidden from the outside world, as well as the complexities of the data flow through the components that make up the service. This component anonymity lets organizations leverage current investments, building services from a conglomeration of components built on different machines, running different operating systems, and developed in different programming languages. Legacy systems can be encapsulated and accessed via Web service interfaces.

• Infrastructure, a commodity — Infrastructure development and deployment will become more consistent across all the different enterprise applications. Existing components, newly-developed components, and components purchased from vendors can be consolidated within a well-defined SOA framework. Such an aggregation of components will be deployed as services on the existing infrastructure resulting in the underlying infrastructure beginning to be considered more as a commodity element.

• Faster time-to-market — Organizational Web services libraries will become the core asset for organizations adapting the SOA framework. Building and deploying services with these Web services libraries will reduce the time-to-market dramatically, as new initiatives reuse existing services and components, thus reducing design, development, testing, and deployment time.

• Reduced cost — As business demands evolve and new requirements are introduced, the cost of enhancing and creating new services by adapting the SOA framework and the services library, for both existing and new applications, is greatly reduced. The learning curve for the development team is reduced as well, as they might already be familiar with the existing components.

• Risk mitigation — Reusing existing components reduces the risk of introducing new failures into the process of enhancing or creating new business services. As mentioned earlier, there is a reduced risk in the maintenance and management of the infrastructure supporting the services, as well.

• Continuous Business Process improvement — A SOA allows a clear representation of process flows identified by the order of the components used in a particular business service. This provides the business users with an ideal environment for monitoring business operations. Process modeling is reflected in the business service. Process manipulation is achieved by reorganizing the pieces in a pattern (components that constitute a business service). This would further allow for changing the process flows while monitoring the effects, and thus facilitates continuous improvement.

• Process-centric architecture — The existing architecture models and practices tend to be program-centric. Applications are developed for the programmer's convenience. Often, process knowledge is spread between components. The application is much like a black box, with no granularity available outside it. Reuse requires copying code, incorporating shared libraries, or inheriting objects. In a process-centric architecture, the application is developed for the process. The process is decomposed into a series of steps, each representing a business service. In effect, each service or component functions as a sub-application. These sub-applications are chained together to create a process flow capable of satisfying the business need. This granularity lets processes leverage and reuse each sub-application throughout the organization.

The promise of web services as an enabling technology is that it will enhance business value by providing capabilities such as services on-demand and, over time, will transform the way IT organizations develop software. It quite possibly might even transform the way business is conducted and products and services are offered over the Web in communities of interest that include trading partners, customers, and other types of business partnership. What if all of your applications shared the same transport protocol? What if they all understood the same interface? What if they could participate in, and understand the same transaction model? What if this were true of your partners? Then you would have applications and an infrastructure to support an ever changing business landscape; you would have achieved on-demand. Web services and SOA make this possible for applications.

More on this topic