Development Process Overview

The Red Hat SOA Development process is a light weight, business process focused approach to service development. This is not a process for:

• assessing      the benefits of SOA to an organization

• planning      a migration to a SOA architecture

• choosing      hardware or software technologies to support SOA

• developing      an enterprise SOA strategy

• managing      a SOA project

While those are all useful things to do, this process assumes:

• the      decision has already been made to implement one or more business      processes using a SOA approach

• these      business processes have been identified

• the      overall project has been planned

This methodology is not a replacement for OOAD, Agile, Extreme Programming, or other development processes that may be in use; rather it is meant to complement these existing processes by placing emphasis on business processes and services.

SOA is not a technology; its benefits cannot be realized by purchasing a product (such as an ESB or a BPEL engine), or by implementing a particular technology (e.g., Web services). SOA requires a new way of developing applications, one that focuses on business processes and individual services.

To be successful, a SOA Project must:

• introduce      a formal link between the design time and run-time to ensure the      delivered implementation is aligned with the originating      requirements.

• continuously      validate the executing events to ensure the implementation remains      aligned with the specifications.

• provide      overall visibility of the inter-dependencies between co-operating      services to assess the impact of an implementation change before      such change is introduced.

These requirements presuppose a formal development process that documents requirements in a meaningful and machine readable way and traces those requirements electronically through to system deployment and execution. This is the goal of a testable architecture.

The Red Hat SOA Development process is meant to be iterative, agile, and relatively light weight. The process does not require particular artifacts be created (although is does suggest the creation of certain artifacts). The process does not require formal approvals, sign-offs, etc (although such things could be overlaid with the process). The process does not require the use of specific modeling tools, although it  does describe the use of Project SAVARA tooling and recommend their use.

The process is defined as some number of iterations of a group of activities referred to as "Service Development Iteration." A single iteration is a (semi-) sequential execution of tasks covering what is in essence a complete typical life cycle, starting with requirements gathering and ending with deployment and monitoring. This process could be used in a "waterfall" manner by executing exactly one iteration, where each task is performed completely at the appropriate time (sequence). The typical project will be incremental and iterative, not "waterfall." In this case, the project will consist of a series of iterations, where those iterations may be overlapping and thus the changes from one iteration need to be verified against previous complete or on-going iterations

The main phases of a service development iteration are:

• Perform      Business Analysis

• Create      Architectural Models

• Perform      Service-Oriented Analysis

• Perform      Service-Oriented Design

• Develop      Services

• Test      Services

• Deploy      Services

• Monitor      Services

Note – these phases, and the following diagram, are based, with some modifications, on the work of Thomas Erl and described in his book “Service-Oriented Architecture Concepts, Technology, and Design” Erl[2005].

Iteration occurs between different phases. At one level, the Top Down Business Analysis continues in parallel with the other phases. This allows business analysts to identify requirements for one or more business processes, provide these to the software architects who model these requirements at the same time the business analysts continue to identify requirements for other business processes.

Iteration also occurs between the other phases. Artifacts, e.g. message schemas, may be initially created, perhaps in the architecture phase, but not finalized until the service-oriented design phase. This finalization may impact other models created in the architecture phase, requiring re-validation of these model.