Accenture Software
ALIP Technical Presentation
Copyright © 2010 Accenture All Rights Reserved. Accenture, its logo, and High Performance Delivered are trademarks of Accenture.
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
Copyright © 2010 Accenture All Rights Reserved.



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
2
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
positioning for the future
Copyright © 2010 Accenture All Rights Reserved.
3
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
 Isolate Data from Logic
Copyright © 2010 Accenture All Rights Reserved.
4
ALIP Architecture – Logical
ALIP Front End
Customer
Servicing
Underwriting
New Business
Policy servicing
Workflow and
business process
management
Service Layer
ALIP Back End
Collection/Disbursement
Third party management
Claims processing
Individual policy management
Batch treatments
Group policy management
Product Factory
Organization
Authorization
Commissioning
Printing
Interfaces
Accounting
Reporting
Reinsurance
Common Calculation
Engine
Copyright © 2010 Accenture All Rights Reserved.
3rd Party
Policy
Administration
Engine
Optional usage of ALIP calculation
engine by 3rd party system
Products
Rules
User defined
Functions
Other
Common
Functions
Tables
5
ALIP Architecture – Physical
Web Server
J2EE Application Server
Static Content/Images/HTML
Presentation
Web Application (WAR)
EJB Application (EJB-JAR)
Other Components
Other(JAR)
Components
(JAR)
Product Component (JAR)
Business,
Product,
and
Data Flow
Product Interface
Product Calc Engine
Product Rules
Calculation Engine
Database Server
Copyright © 2010 Accenture All Rights Reserved.
Data Access
6
Development Tools & Languages
Languages
Development Tools





Presentation Layer
 JSP
 JavaScript
Application Logic
 Java
Back End Components
 Java
 Cobol 2
Database
 SQL




Copyright © 2010 Accenture All Rights Reserved.
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
7
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)
Versions listed in italic bold are preferred
Copyright © 2010 Accenture All Rights Reserved.
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.
8
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
Copyright © 2010 Accenture All Rights Reserved.
9
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
enablement of rules centricity
Copyright © 2010 Accenture All Rights Reserved.
10
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
Copyright © 2010 Accenture All Rights Reserved.
11
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
purpose and type of question
Copyright © 2010 Accenture All Rights Reserved.
12
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
Copyright © 2010 Accenture All Rights Reserved.
13
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
Copyright © 2010 Accenture All Rights Reserved.
14
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
 Designed for simple integration with existing third party source control.
Copyright © 2010 Accenture All Rights Reserved.
15
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
Copyright © 2010 Accenture All Rights Reserved.
16
Change Management Process
One Enhancement SVN Branch 1
Change request, Assigned
to developer
(Specification or Defect)
Is change
request
large
enough to
require a
branch?
Branch
from
Trunk
Developer /
Configurator
makes
changes
QA tests on
branch site
& peer code
review
Once
approved,
Merge to
Trunk
One Enhancement SVN Branch 2…N
Branch
from
Trunk
Developer /
Configurator
makes
changes
QA tests on
branch site
& peer code
review
Changes made directly on Trunk
Developer
gets latest
code
Developer /
Configurator
makes
changes
Changes
are signed
into trunk as
single
changeset
Enhancement Enters
Queue to be merged
back to trunk
Once
approved,
Merge to
Trunk
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
 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.
Copyright © 2010 Accenture All Rights Reserved.
17
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.
Copyright © 2010 Accenture All Rights Reserved.
18
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.
Copyright © 2010 Accenture All Rights Reserved.
19
User Experience
Copyright © 2010 Accenture All Rights Reserved.
20
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
Copyright © 2010 Accenture All Rights Reserved.
21
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
Copyright © 2010 Accenture All Rights Reserved.
22
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
Copyright © 2010 Accenture All Rights Reserved.
23
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
Copyright © 2010 Accenture All Rights Reserved.
24
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
Copyright © 2010 Accenture All Rights Reserved.
25
Integration
Rules as Web Services
Copyright © 2010 Accenture All Rights Reserved.
26
Integration
Example: ALIP Documentation Wiki
Copyright © 2010 Accenture All Rights Reserved.
27
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
without code.
Copyright © 2010 Accenture All Rights Reserved.
28
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
Copyright © 2010 Accenture All Rights Reserved.
29
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.
30