SOA Implementation Approaches

Implementation strategy approach

1.1 Design criteria

Establish the Business Strategy and goals.

Here is an Example of TDC. The important thing is to establish what BP are trying to achieve that set KPI Metrics and goals that leverage this.

The TDC requirements split the solution into five major groups with a sixth optional.

• One common Customer Model and Database

• One common Product Catalogue for all products (BSS and OSS)

• BPM for automation of end-to-end business and enterprise production processes including order management

• EAI

• Service Catalogue and Management

• Identify and Access management (IAM) Optional

In our solution both Customer and Product models are held in the Siebel CRM tool.

The BPM tool is provided by Intalio Client and Server.

EAI functionality and Service Catalogue management is provided by BEA

Identify and access management is proposed to be handled by the CDI within the Siebel product.

BAM and security framework is proposed to be handled primarily within the BEA framework also.

The key concept in e4 Architecture is that it is a holistic approach where all layers and components play a part in this solution. Our implementation approach is based on this premise and is a key concept in a Service oriented architecture and Process oriented architecture. The definition of services and their orchestration and routing is achieved by a combination of front end and back end systems held together by a comprehensive EAI and service business architecture.

Hence the deployment strategy and phasing is to implement ALL of the solution stack at the start and to then develop integration services in an evolutionary path.

1.2 SOA / POA Services Design and Development Life cycle

The strategic concept in the e4 framework is to establish the end to end capability to drive business process value. This is a central element of the enablement of services in an SOA primarily because:

• Development of application integration functions on their own does not enable business processes without a set of orchestrated process activities held together by a set of business rules and services bus that call the functions in a meaningful way

• Managing changes in a design and delivery cycle is significantly enhanced by just managing those changes at the BPM process level. This makes for a much more rapid change of the ;process and redeployment of the new solution. This is enabled by having in place a set of tested process fragments and IT services in a registry that can be easily accessing and applied to a new process. Where changes to these process and IT services are needs then thje SOA development tolls and the centralised control of the Services catalogue means this too can be managed in a coordinated and faster way (based on well defined service schema standards).

The following diagram described the concept of linking the services through the SOA / POA stack. Platforms have services exposed though web services (or in the case of transaction such as batch or complex transactions defined in a transaction

Figure 3 Stack concept for SOA services

management function). These are defined in the EAI layer to establish the Services layer and services catalogue. These “IT Services” are then used in specific business process activities in the BPM and the BPM process models become “executable” as they are tested and deployed as working BPM processes. This established the Process layer and Process catalogue of reuse business process fragments (elements of processes that call IT services and can be reused in other business process models as executable subprocess). The Presentation layer is how the results are visualised and interacted with both in terms of the business activities of users at run-time and in terms of the developers and process designers at design-time quering the services registry.

1.3 The Process Thread Approach

The approach to developing and deploying the services in the e4 architecture is based on an evolutionary approach.

The key aspect of this approach is to first implement the components of the solution architecture for all the technology levels, as described in the last section.

1. The next set of sets to deploy reusable services is through identifying specific business processes and focusing on deploying a business set of processes and associated IT services. That is not to take a “big bang” approach but to deliver a controlled set of services that are tested and working for specific Business process (e.g. Purchase to pay; order to cash; New product introduction) The following diagram identified the sequence of events. As a Process thread is implemented ; further process fragments are identified and the expansion of the services is moved across the platforms and business areas in a controlled and risk managed way.

Figure 4 Process Thread Strategy for SOA/POA Deployment

1. The Development of Platform specific web services and transactions to exposure required functions

2. These IT services defined by the API and Service schema specifications are then registered in the services catalogue for deign time reuse

3. The specific business process is built in the BPM and using selected IT services

4. The business process is implemented from the BPM establishing a verified process and service catalogue.

1.4 Data Architecture and Standards Schemas

Data and standards are key to developing the services. This is not described in detail in this document but the following points are defined:

• The definition of the data , syntax, semantics and behavioural use are key to establishing a common definition of what the Service and business process data throughput and conditions are

• Standards for Web services WSDL, SOAP, XML, UDDI and other standards are necessary to ensure interoperability.

1.5 Business value from the Process Thread Evolutionary approach

The business value for TDC in following this approach to BPMS activation are manifold but have the following key features:

1. Installation of the SOA / EAI / Service Business Infrastructure established the core framework

2. Build the services register established a visual library of services.

3. Established both legacy and new COTs services enables a setup of a new target architecture in parallel with the old.

4. Decoupling legacy backend systems by the services exposure

5. Introducing the principle of going through the services register for all services integration patterns requiring these services

6. Establishing reusable design discoverable services

7. Evolutionary rollout of IT services and process fragments (evolution of run-time discovery and binding)

8. Minimising risk to current operations

9. Decoupled data migration and meta data design – enable this to run in parallel with services design lifecycle.

Overall the approach of e4 and POA/ SOA/ BPMS uses the thought leadership of CSC with proven POC , e4 and POA, SOA framework.

Buy following a bottom-up installation of the infrastructure and in parallel a top down phased delivery of process enabled deployments minimises the risks and at the same time builds the core reusability framework of the SOA.

#SOA #ProjectManagement #ArchitectureGovernance