copyright © 2010 accenture all rights reserved. accenture, its logo, and high performance delivered...

Copyright © 2010 Accenture All Rights Reserved. Accenture, its logo, and High Performance Delivered are trademarks of Accenture.

Accenture Software

ALIP Technical Presentation

2Copyright © 2010 Accenture All Rights Reserved.

Technology/ArchitecturePrimary Features/Design Principles

Customizable Business Experts can innovate without

the delay and high costs of traditional programming

Modular Thin presentation supports multiple

channels Abstract componentized design resists

obsolescence Based on Standards

Standard development tools/languages

Standard infrastructure/administration Standard communication/formats

Platform Neutral Avoids third-party lock-in Includes small footprint

environments Open

Published API and Database Simplifies integration Simplifies upgrades

Simple Strong “Keep it Simple”

approach Careful use of J2EE Let the platform handle the

hard work


Technology/ArchitectureLogical Layers of Applications

Foundation of pre-built Life Insurance components

Common infrastructure and services

User driven assembly of business processes

Achieve many benefits of a full SOA now while positioning for the future


Physical TiersLogical Layers of Application

Presentation Thin

Application/Model Ease UI development Encapsulate session

state Cache API requests

Process/API Orchestration Declarative Transactions Declarative Exposure

Component Business Logic/Engines Decoupled and

Replaecable Data Access

Isolate Data from Logic

5

ALIP Architecture – Logical

Copyright © 2010 Accenture All Rights Reserved.

ALIP Front End

New Business Underwriting Customer Servicing Policy servicingWorkflow and

business process management

Service Layer

3rd PartyPolicyAdministrationEngine

ALIP Back End

Product Factory

Individual policy management

Common CalculationEngine

Products Rules

User defined Functions Tables

Other Common Functions

Optional usage of ALIP calculation engine by 3rd party system

Group policy management

Batch treatments

Claims processingThird party management

Collection/Disbursement

Accounting

Commissioning

Printing

Reporting Authorization

Reinsurance

Inte

rfac

es

Organization


ALIP Architecture – Physical

Web Server

J2EE Application Server

Static Content/Images/HTML

Web Application (WAR)

EJB Application (EJB-JAR)

Other Components (JAR)

Product Component (JAR)

Product Interface

Product Calc Engine

Database Server

Product Rules

Calculation Engine

Other Components (JAR)

Presentation

Business, Product, andData Flow

Data Access

Development Tools & Languages


Presentation Layer JSP JavaScript

Application Logic Java

Back End Components Java Cobol 2

Database SQL

Version Control Subversion ClearCase

IDEs / Debugging Eclipse, RAD NetExpress IDE

Build Maven, Ant TCL

Quality Purify, JProbe, Junit, ACQT HP Quality Center FindBugs, PMD

Data Modeling DataArchitect, ERWin

Development ToolsLanguages

Supported Platforms


Web Server IBM HTTP Server (bundled with WebSphere)Apache 2.0IIS 5.0+

Application Server WebSphere 6.1WebLogic 10.xTomcat 6 (For laptop deployments of the front-end)

Java JDK 1.5+(the JDK bundled with the application Server.)

Database Oracle 10g Oracle 11gDB2 9.x Enterprise Edition Derby (open source database for front-end on laptops)

Messaging Middleware IBM MQ SeriesJCICS Cobol / Cobol EnterpriseIntegrated JMS server with application server.Apache ActiveMQ V4.1+ (For laptop deployments)

Operating System AIX 5.3/6Solaris 10Windows 2003 Server, Windows XPLinux – (Red Hat Linux Enterprise edition or SUSE)Ibm z/Os 1.9 or higher (for Cobol layer)

Commonly used Server Hardware

IBM P5 seriesSun Solaris T Series (java / UltraSparc2)Sun Solaris M series (non-java / Sparc64)Intel based serversMainframe (for Cobol layer)

ALIP was validated on zLinux/s390x using WebSphere 6.1, DB2 9.1 and SUSE Enterprise 10. Support is not yet available for this platform.

Versions listed in italic bold are preferred

Rules Engine Architecture


Business users design pages using the Page Builder

Pages can invoke the Rules Engine for validations and follow up questions

Rules Engine can invoke underlying Business API through XML payloads

Pages can be grouped and tied together to form a workflow

Workflow can leverage the Rules Engine to route to the user through different paths depending on the process or user’s answers

The entire orchestration layer uses XML, allowing the configurable process to front non-ALIP systems, such as an ESB or third-party policy administration system

Rules can be auto-deployed as web service operations


Rules ManagementOverview

Product Rules Key IGO enabler Configurable coverage definition Centralized features utilized across coverage base, Robust calculation support and transactional events

Page Group Rules for Data Collection Data collection needs to support business processes Nuanced support for a variability of data capture workflows Create and maintain with ease

Business Rules Configuration to drive process innovation Drive workflow and follow up automation Insight into business rule execution to transform processes Expose as web services to support ease of integration and

enablement of rules centricity


Rules ManagementProduct Rules

Data driven product engine to roll products out to market in fast/efficient manner Key IGO enabler

Includes Coverage definition Centralized features Robust calculation support Transactional events Product structure and composition rules Tariffs definition Calculations Rules Underwriting Rules

Test and simulation environments support the validation phase before the execution environment


Rules ManagementPage Development

The Page Management Interface supports the creation of Pages, Questions, Answers, Conditions, Reflexive Questions, Formatting, etc.

Pages Specify page name and description

(description displayed at run time) Attach rules to be run when entering or

leaving the page Pages can be inserted between other pages

or added to end of list Questions

Robust and flexible interface for configuring questions

Many types of answer controls supported (Text boxes, Drop down list boxes, Radio buttons, as well as pre-defined controls)

Numerous properties to be set based on purpose and type of question


Rules ManagementBusiness Rules

Customization is supported across: Data collection needs to support business

processes Various design templates and features to

leverage Variability of data capture workflows to support

any nuances Create and maintain configurable business

processes Business rules to drive process innovation

Business edits that leverage product engine Drive workflow automation, follow up

automation Enable data mining of business rule to

transform decision-making processes Expose as web services to support ease of

integration and enablement of rules centricity


Rules ManagementWorkflow Development

Workflows that control all business processes in the system can also be configured

Defines the workflow for a given business process. Examples include:

Application entry Financial transactions entry Underwriting execution Claims management

Workflow services drive the front end flow according product type and channel

Routing based on product and business object state

User Authorizations to perform specific process tasks based on profiling structure


Rules ManagementPromotion, Version Control, and Migration

Promotion tool migrates configuration between ALIP systemsTreat configuration the same as codeUses Web Services to communicate with multiple ALIP systemsSimple directory based repository by defaultConfiguration artifacts stored as XMLDesigned for simple integration with existing third party source control.

Rules Management Replicating in Multiple Environments


Stable “Trunk” version for ongoing development

“Feature branches” used for enhancements

Deployed and tested in isolation before merging to trunk

Trunk state is tagged during releases Fixes are made against release

version If applicable, fixes are merged back to

Trunk for the next version Both code and configuration can be

patched or promoted respectively

17

Change Management Process

Copyright © 2010 Accenture All Rights Reserved.

Change request, Assigned to developer(Specification or Defect)

Is change request large enough to require a branch?

One Enhancement SVN Branch 1QA tests on branch site & peer code

review

Developer / Configurator

makes changes

Branch from Trunk

Once approved, Merge to Trunk

One Enhancement SVN Branch 2…NQA tests on branch site & peer code

review


makes changes

Branch from Trunk

Once approved, Merge to Trunk

Enhancement Enters Queue to be merged back to trunk

Changes made directly on TrunkChanges are signed into trunk as single changeset


makes changes

Developer gets latest code

Day 1Merge

EnhancementsCode Freeze

Day 2Merge


Day 3Acceptance

TestingBug Fixing

Day 4Acceptance

TestingBug Fixing

Day 5Acceptance

TestingBug Fixing

Regression on Previous cycle snapshot, enter bugs for correction

Day 1Merge


Day 2Merge


Day 3Acceptance

TestingBug Fixing

Day 4Acceptance

TestingBug Fixing

Day 5Acceptance

TestingBug Fixing

Regression on Previous cycle snapshot, enter bugs for correction

Day 6Merge SIP


Day 7SIP Acceptance

TestingBug Fixing

Day 8SIP Acceptance

TestingBug Fixing

Day 9Acceptance

TestingBug Fixing

Day 10Snapshot for

Regression TestCode Freeze

Performance Test on Previous cycle snapshot, enter bugs for correction

Day 6Merge SIP


Day 7SIP Acceptance

TestingBug Fixing

Day 8SIP Acceptance

TestingBug Fixing

Day 9Acceptance

TestingBug Fixing

Day 10Snapshot for

Regression TestCode Freeze

Performance Test on Previous cycle snapshot, enter bugs for correction

Change requests large enough to require a separate branch may take a few days or weeks. Each enhancement has its own timeline for completion independent of trunk development lifecycle.

All changes for an enhancement, including data configuration are signed in as a single changeset.

Change requests small enough not to require a separate branch are typically bug fixes or minor enhancements. Example: change format on a data element on a page.


System Development - Two Week Lifecycle

The lifecycle above represents the main development trunk of the system. Each enhancement has an independent lifecycle.

During any development cycle, the development manager may elect to not merge code and skip a cycle to focus on making corrections to trunk.

The performance test is planned to be executed once every other cycle. Merges are not scheduled during the final two week development cycle before a system

release.


Process Benefits

Process significantly reduces wasted labor by concurrent changes adversely impacting each other on a daily development basis. Enhancements large enough requiring a branch are isolated

from trunk activity, insulate both the developer and the rest of the development team.

Process is flexible enough to allow development to be nimble, to allow “direct change” vs. “queued change” as directed by the development manager.

Change process using Subversion allows isolation of distinct changesets to be rolled back or ported to other ALIP versions.

Development cycle allows queuing of merging disruptive large enhancements to trunk at discretion of the development manager. Allows development manager to control trunk stability. Regression testing before and after makes it easy to identify

defects introduced by the enhancement.

User Experience


Internationalization


Features Single installation supports multiple

languages Unicode/UTF-8 Same web pages for all languages Locale tied to each request Date, Currency formats, Collation Jurisdictions, Addresses Tax Calculations Maintenance by Translators (non

programming) Batch operations by region


Scalability and Failover

Clustering Stateless design Serializable web session Supports seamless fail-over

Best Practices No single point of failure Large-grain interfaces Transfer object design pattern Always rely on pooling


Security Architecture

Authentication Single Sign On (SSO) Container-based authentication (JAAS) Turnkey Custom

Authorization Access Control Lists (ACL) Group-based authorization Security level accessible by rules Insurance-aware permissions

Non-repudiation Auditing Version control for rules and questionnaires

Encryption Transport/Wire (SSL, SFTP) Password hashing Data encryption


IntegrationWeb Services and Integration Mechanisms

User interface integration Mashups Imaging systems

Message Based Accept XML, transform and communicate Adapters for standard formats like

ACORD Flexible transports

Web Services Enabled API Full API exposed as WS-I compliant

services Expose User Created Rules as Services

Application/Programming Level Swap out or extend internal components Many technical options

Open relational database Provided tools to simplify extracts and

reports

IntegrationOpen Relational Database


20+ Logical Schemas Map to Components

Design Conventions Normalized Master/Detail Named Values for Dynamic Sequential Keys Isolated Customizations

Default Data Lookup Tables

Initial Data Initial Users/Groups Sample Rules

IntegrationRules as Web Services


IntegrationExample: ALIP Documentation Wiki


IntegrationFrom the Traditional to the Modern Approach


Traditional Approach ALIP acts as a hub and handles data

transformation internally Transformations are too complex to do in

configuration, requiring code ALIP must handle multiple transport types

(SOAP, JMS, Custom) Some transports like SOAP endpoints are

too complex to handle without generating code so they are custom.

Modern Approach ALIP communicates with an ESB using its

own canonical data formats Custom code no longer needed since

transformation and communication is externalized to the ESB

ALIP needs only a small number of generic transports (SOAP, JMS)

ESB Tools can handle transformations without code.

IntegrationALIP SOA / ESB Strategy


Scenario: ALIP is a front end to several existing

back end systems Leverage process-driven design to

delegate service requests

WebSphere ESB Hosts mediation layer and

transformations leveraging ALIP schema.

Allow the customer to manage the integration layer

Reduce complexity and customization within ALIP

Use third party transformation tools (WebSphere Transformation Extender)

Customer chose ACORD as a standard format within the ESB

ALIP/ACORD mappings maintained as part of base

Future SOA Related Enhancements


Continued Path Continued direction to enable our customers to

leverage third-party SOA infrastructure and tools Expose ALIP data and functionality to

encourage the creation of composite and situational business applications outside of ALIP

Leverage dynamic rules as a flexible way to implement services

Example Joint demonstration with IBM using WebSphere

Process server Leverage standard BPEL to design an “Agent

Approval” process. Seamless mix of ALIP services in a larger

process flow. Shared J2EE platform advantages

(transactions, Java/SCA service bindings) Augment and embellish with other services

without modifications to ALIP (Email notification).

copyright © 2010 accenture all rights reserved. accenture, its logo, and high performance delivered...

Documents

rules engine architecture

application server websphere

trademarks of accenture

questions rules engine

web server ibm http

cobol layer alip

logic slide

preferred slide