160 likes | 276 Views
An Insurance Industry Perspective Making the Web of Services Real. W3C Workshop, Bedford, MA – February 2007. The Hartford Financial Services Group Inc. Founded in 1810 One of the largest investment and insurance companies in the United States. Fortune 100 company 30,000 employees
E N D
An Insurance Industry Perspective Making the Web of Services Real W3C Workshop, Bedford, MA – February 2007
The Hartford Financial Services Group Inc. • Founded in 1810 • One of the largest investment and insurance companies in the United States. • Fortune 100 company • 30,000 employees • Two Companies: • Hartford P&C – auto, home, business insurance • Hartford Life – investment plans, life insurance, group benefits
Introduction to the three use cases • A non-technical problem: Achieving a shared-services IT model • Rules in a Web of Services • Dynamic UI’s
Context The Web of Services needs to extend from a complex legacy base Complexity in the automation environment is a growing problem, requiring significant maintenance spend and hindering business agility and flexibility Business Functions Environment Complexity Tech Complexity 10+ Dev Languages • Value chain is comprised of 200+ unique business functions • Describing all discrete functions performed by applications in the portfolio • Business function redundancy across applications is common • Underwriting data capture is performed in many different applications Over 250 technologies and technical platforms • Hundreds of unique business applications in the eB&T portfolio • Complex automation environment requires significant spend for ongoing maintenance • Tightly coupled applications make it difficult to leverage and reuse existing business capabilities Multiple versions of vendor tools
The Pushback Model 2 Scenarios that impede innovation: Biz/IT Wall Business Innovation Demand IT invokes Newton’s 3rd 1 Biz/IT Wall Supply Technology Innovation Business invokes Newton’s 3rd 2
Services Information Management Future Platform Building the Technology Platform one rationalization step at a time … Foundational Architecture Application Rationalization Step The P&C Technology Platform: Common IT capabilities enabling business capabilities
The Collaboration Model 3 Scenarios that foster innovation: Biz/IT Asset Business Innovation Demand 1 Biz/IT Asset Supply Technology Innovation 2 Biz/IT Asset Business Innovation Supply 3
Use Case 1: Achieving a Shared Services IT Model • The Problem • SOA has been bottom-up • Technology availability and infrastructure implementation not the issue • Planning, governance and organizational issues • Why it matters • Business agility, TCO • The need is there, the technical solutions are there • How can we do this? • A decision support system for IT Planning and Strategy • Maybe the Semantic Web • Maybe an industry consortium
SOA SEMCI UDDI Edit SOAP WSM SOAP WSM XML->AL3 SEMCI Orch ACORD XML WSM XML Security Appl SOAP Quoting Engine WSM WSM ACORD XML WSM AL3->XML WSM DMZ Echo SOAP
Use Case 2: Rules in a web of services • The Problem • “Rules” have been applied by IT to solve many business problems • Some “rules” can provide business agility • “Rules” means many different types of solutions, esp. within an SOA, from business rules, to edit rules to metadata to governance • “Rules” can be and are implemented on many types of platforms without any specified criteria • Why it matters: TCO, Agility. • Possible Approaches: • A taxonomy of rules, and standardized (maybe automated) ways to deploy different types of rules on different platforms. • A platform-independent way of specifying rules • A distributed, secure architecture for rules
Use Case 2: Rule types within The Hartford P&C Rule Definition: A “Rule” is a statement that defines or constrains some aspect • Event Rules: Rules that govern the User Interfaces and actions/events taken. • Syntax Rules: Rules that relate to presence/occurrence of data elements, their data type and structures. (Data Collection rules that may be executed with schema validation and/or XPATH ). • Conditional Rules: Rules that apply optionally or under the conditions/values of other data elements. (Data validation rules) • Relational Rules: Rules that occur across multiple conditions of a given process or transaction and may across multiple screens when exposed to a user interface. • Business Rules: Rules that the business is closest to and might have requirements for analytics (i.e. Risk Assessment/Scorecard, Underwriting, Product, Pricing, Claims Processing, and other rules in the enterprise decision management space) • SOA Run-time Governance Rules: Rules that enforce SOA policies at run-time, such as SLAs, security, etc.
SOA SEMCI UDDI Edit SOAP WSM SOAP WSM XML->AL3 SEMCI Orch ACORD XML WSM XML Security Appl SOAP Quoting Engine WSM WSM ACORD XML WSM AL3->XML WSM DMZ Echo SOAP
Use Case 3: Dynamic UI’s • The Problem: Need to dynamically capture user information to provide insurance information or quotes. Rules based questions performed on the back end lower usability. No standards around rules based UI solutions. • Why it matters: Customer experience. Speed to market. • Possible Approach: • Standardize on frontend rules-based UI solutions • Tie existing standards together • W3C: XForms, XSLT, XPath, XML • JCP: JSR-168/286, JSR-94, JAXP • OASIS: WSRP
Q & A Thank You Balaji Prasad Director, Enterprise Architecture & Benjamin Moreland Director, Foundation Services Enterprise Architecture Group The Hartford Financial Services Group