Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Mark Norton (Idiom Limited)

•
•

1. An actuary at a major Australian insurer developed an adjustment to their credit policy to reduce unnecessary referrals in the automated insurance underwriting process. This was tested and approved within two weeks by one person without IT involvement. 2. A product team at the same insurer took ownership of definitions for complex insurance products, including continuous updating of schemas, rules, forms and reference data with daily releases, all without IT involvement. 3. The document argues that separating external business concepts from internal IT concepts allows business subject matter experts to independently manage products and services through abstract models, reducing IT delays and increasing business agility.

1 of 17
Perpetual Motion in Financial Products Mark Norton IDIOM Limited
Business Agility in Action – business led policy improvement Actual Use Case – One of top 4 Australasian insurers Actuary identifies opportunity to reduce the referral rate for automated insurance underwriting Working alone, develops adjustment to credit policy to mitigate unnecessary referrals Verifies improvement and ensures no unintended consequences by testing the challenger vs incumbent policies across the full product portfolio (>500k policies) Generates new Credit Policy narratives for Board and APRA approval Submits new policy to production – automated overnight process ALL WITHOUT IT INVOLVEMENT ALL IN TWO WEEKS ELAPSED ONLY ONE PERSON END TO END
Business Agility in Action – nimble, continuous, perpetual Actual Use Case – One of top 4 Australasian insurers SME team takes custody of product definitions for high-end, tailored insurance products Including data schemas, life-cycle decisions, forms, business documents, reference data 50-60 large, maximum complexity products (thousands of risks, multi-billions cover per policy) 100’s of active underwriters Continuous, perpetual versioning of schemas, rules, forms, documents, reference data Continuous total portfolio testing (policy simulations, what-if, regression) Automated pipelining* of schema changes Automated deployment cycle with single manual step to verify deployment process compliance ALL WITHOUT IT INVOLVEMENT DAILY RELEASE CYCLE FOR INSURANCE PRODUCTS BY PRODUCT SMEs
What is the matter with IT High cost, high risk, long time for systems that are too inflexible Requirements* that start badly as narrative and get worse through multiple one-way transformations to executable code What is a requirement (singular)? A process? A transaction? No party can confirm what is written as computer code matches what was intended by the narrative Deliberate subjugation then assimilation of business concepts into IT concepts Business reality is subsumed in IT jargon that has no business relevance (objects, components, layers, standards, notations, processes, etc.) So that business concepts are suffused throughout the code base Losing their identity, integrity, and coherence Technical and business concepts are fused into one single system image Result: Every business change is a full scale IT construction project * Requirements: http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/1354/Requirements-and-the-Beast-of-Complexity.aspx
Agile Improves, but does not Solve the Problem Speed to market is a critical business KPI for development of business products + services Our business users have backlogs for IT resources measured in months to years - assume a current backlog of 6 months Assume a product change takes 1 month to develop and test under waterfall SDLC Assume that agile improves waterfall SDLC by 50% How much better off is the business in terms of its critical KPI? ~8% Agile is a business issue more than an IT issue Speeding up financial product delivery is the objective, not speeding up the SDLC per se Ergo, we need to remove / reduce IT role in financial product + service delivery
Our upside down world “Externalities” are real, perpetual, and mutable, and exist irrespective of any system Real things, real data, real events, real policies e.g. Loans, Policies, Claims, Patients, Passengers, Taxpayers, etc “Internalities” are the IT things that are unseen in the real world E.g. objects, components, layers, standards, notations, processes, etc Systems: a simulacrum* of business reality that is abstract, transient, rigid [*a mere image that does not represent the reality of the original] Much treasure is spent injecting externalities into internalities ! What is real, perpetual and mutable is embodied in something that is abstract, transient, and inflexible We need to reinvent this process – internalities and externalities must be discrete and independent So that what is real, perpetual, and mutable stays real, perpetual, and mutable within systems that are abstract, transient, and inflexible
Build an Agile System, not an Agile Development Process AGILE helps when it addresses the Externalities more than the Internalities Agile must be measured in terms of business agility, not development agility Building systems that fuse externalities / internalities faster and at less cost still = failure Deliver a system that allows business SME’s to build and maintain financial products Separation of concerns – separate externalities and internalities Retain distinct ownership, custodianship, and management of each Business ownership of externalities / IT ownership of internalities Build models of the externalities to be executed directly by the internalities Externalities exist independently before, during, and after internalities Semi-rigid Internalities service agile externalities subject to periodic wholesale replacement Make the relationship between Externalities and Internalities explicit Use meta data to ‘late-bind’ Externalities and Internalities
Externalities Financial Products and Services are Externalities that can be represented by 4 models 1. Data that represents each real world entity and holds its current state (ENTITY DATA) 2. Policies that govern the life-cycle of each entity by controlling the entity’s state transitions (POLICIES) 3. Policy aware event pathways that drive the state transitions for each entity (EVENTS) (forms for human users, services for automated systems) 4. Complex representations of the entity state for external actors (DOCUMENTS / MESSAGES) Entity data is large and complex (e.g. >100k normalised data nodes) Policies come from many sources – distilled into decisions / rules Regulatory – legal, industry best practice Contractual – policies agreed with third parties, contracts Internal – the product and service definitions of the model owner Process Management driven by ‘best, next’ decisions – BINARY BPM Decision driven, just-in-time, dynamic selection of ‘best-next’ activity or process Models of Externalities are not bound to execution technology, location, or platform
Internalities Can be hidden behind a generic transaction container – providing a ‘virtual transaction platform’ for any/all Externality models Includes BAU IT standards, platforms, and infrastructure Security, authentication and authorisation Event management, transaction invocation, transaction resourcing Persistence, record location, record retrieval Routing, communications, message delivery Includes all specialist activities that are defined by technology Web services, communication devices, machine interfaces, etc. (e.g. Send SMS, Address lookup) Scope of internalities is relatively minor Total number of discrete activities is < a few hundred for a large corporate (source: major UK Bank) Total number of LOC is <20% of the complete system image Internalities are not aware of the nature of any business entity or policy Externalities and Internalities only aware of each other via meta data
One System Image but Two Systems
Generic Database Persists Externalities
Generic Business Transaction Executes Externalities
Benefits of Abstracted, Decision Centric Transactions Workflow Efficiency – use policy defined decisions to generate Workflow meta-data “Binary BPM” – the best-next-step determined just-in-time every-time ‘Automate the now’, not the future or the past Align entire universe of dependent systems and actors with new state Timeliness and Accuracy The right question at the right time; followed by the right decisions; and timely, decision controlled follow-up – every where, every time Ease of Use Forms and processes dynamically optimised for different user needs including customers, back-office & administrators, third parties Expanded Transaction Scope Fewer transactions needed because the transaction addresses the entire entity life cycle, not specific state changes
Benefits of Abstracted, Decision Centric Transactions Auditable and Transparent – full audit trail for all data, processes, decisions Business/Systems Alignment – apply the correct business policies for every event, every time Determine whether to offer/allow any product or service, under what terms and conditions, with what costs/charges, then control all downstream consequences – all exactly in accordance with business policy Perpetual Agility Allow improvements to be implemented by SMEs by adjusting the Externalities continuously (without code changes) as the organisation learns Extensible Externalities inherently allow plug’n’play products and services Legacy Rejuvenation Embed transaction container into Legacy systems to enhance capability / extend life
Business Transaction Cycle (Part 1) Event triggers transaction Web service, communication device, machine interface, etc The Internalities (the IT cycle – part 1) Ø  Identify the event and initiate response Ø  Locate an existing entity record or instantiate a new one Ø  Acquire event data for the transaction Ø  Instantiate the relevant ‘policy life cycle’ transaction in the container Ø  THE INTERNALITIES ARE NOT TRANSACTION AWARE The Externalities (the business cycle) Ø  Receive and validate the event data against the current entity state [Cycle the event data through a form or service until acceptable] Ø  Transform the event and entity data into the policy idiom Ø  Execute the business policy and determine the new entity state Ø  Change the state and all state dependent attributes (cost, terms, etc) Ø  Prepare vectors to align all external systems Ø  Prepare workflow data to drive activities and future events
Transaction Cycle (Part 2) The Internalities (the IT cycle – part 2) Ø  When the transaction is completed, receive the entity data in its new state Ø  Persist the new state and archive the old state Ø  Inspect the state meta data for Bringups, Actions, Vectors for secondary events Ø  Extract the workflow meta data and use to drive the activities and secondary events Result Entity state is updated Current and future workflow is actioned All internal and external systems are aligned with this new state STILL ONE SYSTEM IMAGE – NOW IN 2 DISCRETE PARTS
Thanks for listening… Mark Norton IDIOM Limited

More Related Content

Mark Norton (Idiom Limited)

  • 1. Perpetual Motion in Financial Products Mark Norton IDIOM Limited
  • 2. Business Agility in Action – business led policy improvement Actual Use Case – One of top 4 Australasian insurers Actuary identifies opportunity to reduce the referral rate for automated insurance underwriting Working alone, develops adjustment to credit policy to mitigate unnecessary referrals Verifies improvement and ensures no unintended consequences by testing the challenger vs incumbent policies across the full product portfolio (>500k policies) Generates new Credit Policy narratives for Board and APRA approval Submits new policy to production – automated overnight process ALL WITHOUT IT INVOLVEMENT ALL IN TWO WEEKS ELAPSED ONLY ONE PERSON END TO END
  • 3. Business Agility in Action – nimble, continuous, perpetual Actual Use Case – One of top 4 Australasian insurers SME team takes custody of product definitions for high-end, tailored insurance products Including data schemas, life-cycle decisions, forms, business documents, reference data 50-60 large, maximum complexity products (thousands of risks, multi-billions cover per policy) 100’s of active underwriters Continuous, perpetual versioning of schemas, rules, forms, documents, reference data Continuous total portfolio testing (policy simulations, what-if, regression) Automated pipelining* of schema changes Automated deployment cycle with single manual step to verify deployment process compliance ALL WITHOUT IT INVOLVEMENT DAILY RELEASE CYCLE FOR INSURANCE PRODUCTS BY PRODUCT SMEs
  • 4. What is the matter with IT High cost, high risk, long time for systems that are too inflexible Requirements* that start badly as narrative and get worse through multiple one-way transformations to executable code What is a requirement (singular)? A process? A transaction? No party can confirm what is written as computer code matches what was intended by the narrative Deliberate subjugation then assimilation of business concepts into IT concepts Business reality is subsumed in IT jargon that has no business relevance (objects, components, layers, standards, notations, processes, etc.) So that business concepts are suffused throughout the code base Losing their identity, integrity, and coherence Technical and business concepts are fused into one single system image Result: Every business change is a full scale IT construction project * Requirements: http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/1354/Requirements-and-the-Beast-of-Complexity.aspx
  • 5. Agile Improves, but does not Solve the Problem Speed to market is a critical business KPI for development of business products + services Our business users have backlogs for IT resources measured in months to years - assume a current backlog of 6 months Assume a product change takes 1 month to develop and test under waterfall SDLC Assume that agile improves waterfall SDLC by 50% How much better off is the business in terms of its critical KPI? ~8% Agile is a business issue more than an IT issue Speeding up financial product delivery is the objective, not speeding up the SDLC per se Ergo, we need to remove / reduce IT role in financial product + service delivery
  • 6. Our upside down world “Externalities” are real, perpetual, and mutable, and exist irrespective of any system Real things, real data, real events, real policies e.g. Loans, Policies, Claims, Patients, Passengers, Taxpayers, etc “Internalities” are the IT things that are unseen in the real world E.g. objects, components, layers, standards, notations, processes, etc Systems: a simulacrum* of business reality that is abstract, transient, rigid [*a mere image that does not represent the reality of the original] Much treasure is spent injecting externalities into internalities ! What is real, perpetual and mutable is embodied in something that is abstract, transient, and inflexible We need to reinvent this process – internalities and externalities must be discrete and independent So that what is real, perpetual, and mutable stays real, perpetual, and mutable within systems that are abstract, transient, and inflexible
  • 7. Build an Agile System, not an Agile Development Process AGILE helps when it addresses the Externalities more than the Internalities Agile must be measured in terms of business agility, not development agility Building systems that fuse externalities / internalities faster and at less cost still = failure Deliver a system that allows business SME’s to build and maintain financial products Separation of concerns – separate externalities and internalities Retain distinct ownership, custodianship, and management of each Business ownership of externalities / IT ownership of internalities Build models of the externalities to be executed directly by the internalities Externalities exist independently before, during, and after internalities Semi-rigid Internalities service agile externalities subject to periodic wholesale replacement Make the relationship between Externalities and Internalities explicit Use meta data to ‘late-bind’ Externalities and Internalities
  • 8. Externalities Financial Products and Services are Externalities that can be represented by 4 models 1. Data that represents each real world entity and holds its current state (ENTITY DATA) 2. Policies that govern the life-cycle of each entity by controlling the entity’s state transitions (POLICIES) 3. Policy aware event pathways that drive the state transitions for each entity (EVENTS) (forms for human users, services for automated systems) 4. Complex representations of the entity state for external actors (DOCUMENTS / MESSAGES) Entity data is large and complex (e.g. >100k normalised data nodes) Policies come from many sources – distilled into decisions / rules Regulatory – legal, industry best practice Contractual – policies agreed with third parties, contracts Internal – the product and service definitions of the model owner Process Management driven by ‘best, next’ decisions – BINARY BPM Decision driven, just-in-time, dynamic selection of ‘best-next’ activity or process Models of Externalities are not bound to execution technology, location, or platform
  • 9. Internalities Can be hidden behind a generic transaction container – providing a ‘virtual transaction platform’ for any/all Externality models Includes BAU IT standards, platforms, and infrastructure Security, authentication and authorisation Event management, transaction invocation, transaction resourcing Persistence, record location, record retrieval Routing, communications, message delivery Includes all specialist activities that are defined by technology Web services, communication devices, machine interfaces, etc. (e.g. Send SMS, Address lookup) Scope of internalities is relatively minor Total number of discrete activities is < a few hundred for a large corporate (source: major UK Bank) Total number of LOC is <20% of the complete system image Internalities are not aware of the nature of any business entity or policy Externalities and Internalities only aware of each other via meta data
  • 10. One System Image but Two Systems
  • 11. Generic Database Persists Externalities
  • 12. Generic Business Transaction Executes Externalities
  • 13. Benefits of Abstracted, Decision Centric Transactions Workflow Efficiency – use policy defined decisions to generate Workflow meta-data “Binary BPM” – the best-next-step determined just-in-time every-time ‘Automate the now’, not the future or the past Align entire universe of dependent systems and actors with new state Timeliness and Accuracy The right question at the right time; followed by the right decisions; and timely, decision controlled follow-up – every where, every time Ease of Use Forms and processes dynamically optimised for different user needs including customers, back-office & administrators, third parties Expanded Transaction Scope Fewer transactions needed because the transaction addresses the entire entity life cycle, not specific state changes
  • 14. Benefits of Abstracted, Decision Centric Transactions Auditable and Transparent – full audit trail for all data, processes, decisions Business/Systems Alignment – apply the correct business policies for every event, every time Determine whether to offer/allow any product or service, under what terms and conditions, with what costs/charges, then control all downstream consequences – all exactly in accordance with business policy Perpetual Agility Allow improvements to be implemented by SMEs by adjusting the Externalities continuously (without code changes) as the organisation learns Extensible Externalities inherently allow plug’n’play products and services Legacy Rejuvenation Embed transaction container into Legacy systems to enhance capability / extend life
  • 15. Business Transaction Cycle (Part 1) Event triggers transaction Web service, communication device, machine interface, etc The Internalities (the IT cycle – part 1) Ø  Identify the event and initiate response Ø  Locate an existing entity record or instantiate a new one Ø  Acquire event data for the transaction Ø  Instantiate the relevant ‘policy life cycle’ transaction in the container Ø  THE INTERNALITIES ARE NOT TRANSACTION AWARE The Externalities (the business cycle) Ø  Receive and validate the event data against the current entity state [Cycle the event data through a form or service until acceptable] Ø  Transform the event and entity data into the policy idiom Ø  Execute the business policy and determine the new entity state Ø  Change the state and all state dependent attributes (cost, terms, etc) Ø  Prepare vectors to align all external systems Ø  Prepare workflow data to drive activities and future events
  • 16. Transaction Cycle (Part 2) The Internalities (the IT cycle – part 2) Ø  When the transaction is completed, receive the entity data in its new state Ø  Persist the new state and archive the old state Ø  Inspect the state meta data for Bringups, Actions, Vectors for secondary events Ø  Extract the workflow meta data and use to drive the activities and secondary events Result Entity state is updated Current and future workflow is actioned All internal and external systems are aligned with this new state STILL ONE SYSTEM IMAGE – NOW IN 2 DISCRETE PARTS
  • 17. Thanks for listening… Mark Norton IDIOM Limited