Accenture Software. ALIP Technical Presentation

(1)

Accenture Software

(2)

Technology/Architecture

Primary 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

(3)

Technology/Architecture

Logical 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

(4)

Physical Tiers

Logical 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

(5)

ALIP Architecture – Logical

ALIP Front End

New Business Underwriting Customer _Servicing Policy servicing

Workflow and business process management Service Layer 3rd _Party Policy Administration Engine

ALIP Back End

Product Factory Individual policy management

Common Calculation Engine

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 processing Third party management

Collection/Disbursement Accounting Commissioning Printing Reporting Authorization Reinsurance In ter faces Organization

(6)

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, and Data Flow Data Access

(7)

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 Tools

Languages

(8)

Supported Platforms

Web Server IBM HTTP Server (bundled with WebSphere)

Apache 2.0

IIS 5.0+

Application Server WebSphere 6.1

WebLogic 10.x

Tomcat 6 (For laptop deployments of the front-end)

Java JDK 1.5+

(the JDK bundled with the application Server.)

Database Oracle 10g

Oracle 11g

DB2 9.x Enterprise Edition

Derby (open source database for front-end on laptops)

Messaging Middleware IBM MQ Series

JCICS Cobol / Cobol Enterprise

Integrated JMS server with application server. Apache ActiveMQ V4.1+ (For laptop deployments)

Operating System AIX 5.3/6

Solaris 10

Windows 2003 Server, Windows XP

Linux – (Red Hat Linux Enterprise edition or SUSE)

Ibm z/Os 1.9 or higher (for Cobol layer)

Commonly used Server Hardware

IBM P5 series

Sun Solaris T Series (java / UltraSparc2) Sun Solaris M series (non-java / Sparc64) Intel based servers

Mainframe (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.

(9)

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

(10)

Rules Management

Overview

 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

(11)

Rules Management

Product 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

(12)

Rules Management

Page 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

(13)

Rules Management

Business 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

(14)

Rules Management

Workflow 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

(15)

Rules Management

Promotion, Version Control, and Migration

Promotion tool migrates configuration between ALIP systems

 Treat configuration the same as code

 Uses Web Services to communicate with multiple ALIP systems  Simple directory based repository by default

 Configuration artifacts stored as XML

(16)

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

Change request, Assigned to developer (Specification or Defect) Is change request large enough to require a branch?

One Enhancement SVN Branch 1

QA tests on branch site & peer code review Developer / Configurator makes changes Branch from Trunk Once approved, Merge to Trunk

One Enhancement SVN Branch 2…N

QA tests on branch site

& peer code review Developer / Configurator makes changes Branch from Trunk Once approved, Merge to Trunk Enhancement Enters Queue to be merged back to trunk

Changes made directly on Trunk

Changes are signed into trunk as single changeset Developer / Configurator makes changes Developer gets latest code Day 1 Merge Enhancements Code Freeze Day 2 Merge Enhancements Code Freeze Day 3 Acceptance Testing Bug Fixing Day 4 Acceptance Testing Bug Fixing Day 5 Acceptance Testing Bug Fixing

Regression on Previous cycle snapshot, enter bugs for correction Day 1 Merge Enhancements Code Freeze Day 2 Merge Enhancements Code Freeze Day 3 Acceptance Testing Bug Fixing Day 4 Acceptance Testing Bug Fixing Day 5 Acceptance Testing Bug Fixing

Regression on Previous cycle snapshot, enter bugs for correction

Day 6 Merge SIP Enhancements Code Freeze Day 7 SIP Acceptance Testing Bug Fixing Day 8 SIP Acceptance Testing Bug Fixing Day 9 Acceptance Testing Bug Fixing Day 10 Snapshot for Regression Test Code Freeze

Performance Test on Previous cycle snapshot, enter bugs for correction Day 6 Merge SIP Enhancements Code Freeze Day 7 SIP Acceptance Testing Bug Fixing Day 8 SIP Acceptance Testing Bug Fixing Day 9 Acceptance Testing Bug Fixing Day 10 Snapshot for Regression Test Code 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.

(18)

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.

(19)

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.

(20)

User Experience

(21)

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)

(22)

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

(23)

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

(24)

Integration

Web 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

(25)

Integration

Open 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

(26)

Integration

Rules as Web Services

(27)

Integration

(28)

Integration

From 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

(29)

Integration

ALIP 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

(30)

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).