Service-oriented architecture or SOA is an architecture style, not a product or a project. It's an improvement over past architectures in that it captures and uses the best practices of the architectures that came before it. As such, SOA is an evolution in architecture, not a revolution.

Typically the IT department of every organization has applications that can be broadly classified into a back-end and a front-end. The back-end can be considered as the combination of all the business tiers and data tiers of the organization. The front-end layer is the combination of all the presentation tiers.

IT's back-end comprises all the applications developed on J2EE, Microsoft .NET, CICS mainframes and various other technologies that contain the business logic of the organization. It also includes the stored procedures, data in the databases or in various other formats.

The front-end includes all possible business channels, whether Web-based or on the desktop, Web services or Enterprise JavaBeans (EJB) exposed to partners and clients.

SOA comes to play in the back-end. It's an architecture for the organization's backbone. SOA describes a better way of organizing the back-end, providing mainly high flexibility (faster response to change) and the reuse of existing IT assets. These two characteristics are what make SOA most attractive as an enterprise architecture.

For SOA to work, the back-end must be broken up into a set of services. Each service performs a specific business task. Once the services comprising a set are identified, they can be strung together to form a business process.

Essentially, SOA separates the process logic from the business logic. The business logic is made available as services. The process logic is constructed by linking these services.

The procedure of linking the services to form a business process is also referred to as orchestration. Languages like Business Process Execution Language (BPEL) are used to build the process logic.

The orchestration engines provide support for execution of BPEL, thus facilitating the execution of business processes.

We can use BPEL to build the process logic, but how do we build a service? A service is a specific business task. The first step in building a service is to identify the desired services within the system. A business analyst should identify the reusable business tasks and also provide the granularity of the task. Such a task can be exposed as a service.