Agility through Decisioning

Transcription

1 Agility through Decisioning Mark Norton IDIOM Ltd May 2012

2 INTRODUCTION 3 KEY CONCEPTS 4 Requirements and Decisioning 4 Technical Risk Management 5 Data Modeling 5 Project Size 6 Agile Development 6 Architecture 7 Team Structure 8 Testing 8 Project Management 9 ANATOMY OF A DECISION CENTRIC PROJECT 10 A Small Project 10 A Large Project 12 IDIOM PRODUCTS 14 IDIOM Tools 14 The IDIOM Decision Manager 14 IDIOM Forms 17 IDIOM Decision Tracker 18 IDIOM Mapper 18 IDIOM Decision Manager Workbench 18 IDIOM Document Generator 20 Service Offerings 21 WORKING EXAMPLES OF DECISION CENTRIC DEVELOPMENT 22 Examples of Decision Model Complexity 22 Defined Benefit Scheme 22 Payroll Audit and Remediation 23 Examples of High Volume Processing 24 Other Miscellaneous Project Examples 24 Copyright IDIOM Ltd 2015 Page 2 of 25

3 INTRODUCTION This document provides an overview of how IDIOM and prospective customers can engage to reap the benefits of decision centric development. IDIOM is a leader in this field, with the IDIOM Decision Manager being the first tool published (in 2001) under the decision management label. This document assumes that the reader has already assessed the benefits of decision automation and that they desire to move forward with a decision centric approach. IDIOM has evolved its proprietary approach through more than 10 years developing and deploying systems around the world that use decisioning as a central tenet of the application design. This approach is founded on even longer experience with what has come to be termed agile development. We have labeled the approach the Agile Decisioning Approach (ADA) The primary objective of the approach is to defeat the beast of complexity. The beast of complexity as described in the article 1 is largely a product of a traditional approach to requirements gathering and management. ADA introduces an innovative and pragmatic approach to systems development that significantly reduces the requirements burden, while at the same time improving the quality of the systems development outcomes. While the basis of the ADA approach is essentially agile, the major point of difference is that the nucleus around which the agile development process rotates is the concept of decisioning. IDIOM s numerous projects have demonstrated that by using agile methodologies to build out directly from a decisioning core, we can safely evolve requirements on a just-in-time basis without ever needing to specifically address them in the traditional manner. For many projects, this means that the traditional requirements phase is missing entirely this doesn t just reduce the work effort, cost, and time by an amount equivalent to the erstwhile requirements documentation effort, but it can also strengthen the development process and deliver systems that are better aligned with the business need. The requirements are not ignored entirely though they are finally committed to narrative in the form of test scripts and user documentation in the delivery phases of the development when, by definition, they align exactly with the systems as delivered. The IDIOM products have evolved in parallel with the development of ADA and they are mutually supportive. This is not to say that the IDIOM products are tightly bound to the approach in fact IDIOM strongly believes that the approach stands on its own and its objectives can be achieved through use of other products. However, we have carefully tailored the IDIOM products to meet the needs of ADA, and the extent to which this has been achieved is IDIOM s product advantage. IDIOM has also tailored its contract engagement options to support the just-in-time characteristics of ADA. Our service contracts provide a low risk and flexible engagement model that recognizes and encourages full use of ADA without unnecessary commitment or risk. 1 Requirements and the Beast of Complexity, Copyright IDIOM Ltd 2015 Page 3 of 25

4 KEY CONCEPTS The following concepts work together to improve the development efficiency of the ADA approach. An improvement in development efficiency implies smaller projects for equivalent outcomes. As demonstrated by T Capers Jones 2, project development time, cost, and risk are reduced exponentially in proportion to a reduction in development size. On the other side of the ledger, faster development cycle times result in better business alignment and better business buy-in for the evolving system. With the rapid development cycle time that ADA promotes, the relevant business sponsors and subject matter experts (SMEs) can be efficiently integrated into a review cycle that pre-empts traditional requirements analysis. Frequent business review implicitly aligns the evolving system with business expectation (and vice versa) while at the same time educating and acclimatizing business users. It also results in early and frequent testing of core functionality. The outcome at completion of the development phase is therefore a system that is already substantially tested and which is tightly aligned (by definition) with both business needs and expectations, thus significantly reducing the risk of failure or aborted delivery. Requirements and Decisioning Traditional requirements specifications can only be viewed in their abstract form (i.e. narratives, diagrams, etc). It is implausible that a group of people who are likely to have different backgrounds and domain skills will always see these abstracted concepts in the same way certainly, they cannot ever be sure that they are doing so. This fundamental constraint diminishes the value of manual requirements review and truth testing. At the same time, the abstract nature and form of the artifacts means that empirical testing is difficult. The bottom line is that the traditional requirements approach leads to specifications of un-provable quality in terms of completeness, consistency, and correctness. Furthermore, any concerted attempt to either prove or improve these characteristics prior to development means a costly investment in what is essentially just a staging artifact of little long term value. The ADA approach integrates just-in-time requirements elicitation with rapid development approaches. Conceptually, we can think of the ADA approach as an alternative requirements approach that records the requirements in executable form. Furthermore, because of the truncated downstream effort (coding et al) and the risk reduction that this implies, it is plausible to deliver operational systems for a much reduced cost. The essence and starting point for the approach is to focus on core decision making. We use decision centric analysis to distill the root requirements directly from the domain without investing in the more traditional requirements deliverables. The IDIOM Decision Manager is a useful tool for capturing and collating this decision analysis. Of the utmost importance, we can test and prove the decision analysis using any number of past, present, and future use cases to empirically confirm completeness, consistency, and correctness of the decision analysis prior to further development investment. The complete decision analysis and definition cycle should only represent a few percent of the overall 2 Copyright IDIOM Ltd 2015 Page 4 of 25

5 development effort, yet it substantially prescribes the overall solution (both data and process), thereby de-risking these important development aspects. A useful byproduct of the early decision analysis is that it provides valuable feedback to the business SMEs, helping them to clarify and confirm decision making strategies in general, and those required by the project in particular. The requirements artifact that is developed in this early project phase (a decision model ) can be maintained and kept current throughout the development project, then continuing through the life of the system, and in fact continuing to represent and implement the decision making policies of the organization for the life of the organization. The implied absolute separation of decisioning from systems is why ADA recognizes decision making as content within systems (in modeling terms there is a many-to-many relationship between systems and decision models). For the sake of clarity, IDIOM generates decision models into Java and/or C# source code there will be no subsequent development phase for these decisioning requirements (IDIOM refers to a decision model in its generated/compiled form as a decision engine ). Technical Risk Management IT is a rapidly evolving industry, and leading edge developments incur some technical risk by definition. ADA explicitly targets technical risk at the earliest stages of any project, either in parallel with or immediately following the reduction in business risk that is achieved through decision centric analysis as above. Therefore any technical unknowns should be identified and quantified before any further development is undertaken. Technical risk in this case is any technical assumption for which the developer(s) does not have first-hand validating experience. The risk is then quantified by considering the distance between the developer and any first hand source of validating information regarding the technical risk, and the criticality of the technical function that is being addressed by the risk component. A critical component about which the developer knows little is considered highest risk, whereas a less critical component about which a neighboring developer has first-hand experience (presuming that it is positive) would be at the other end of the scale. The ADA approach recommends addressing the risks in priority order with the minimum amount of development that is required to demonstrate that the technical component can meet the functional requirement. For the sake of clarity, this means development and empirical assessment of code in the context of the target application. Once a technical risk has been mitigated, further development can be re-prioritised in accordance with the business delivery priorities and other development dependencies. Data Modeling Data modeling is an important ingredient in any project. For smaller projects, this is often limited to development of schemas for XML documents, with the data being persisted by existing systems. In larger projects and all systems where the ADA project is persisting data itself, complete database schemas are centrally maintained and referenced by all developers. IDIOM data models are physical Copyright IDIOM Ltd 2015 Page 5 of 25

6 models (they are not abstracted there is no concept of a conceptual data model) and are used to generate the database definition this means that any de-normalising becomes real in the model. Our belief is that this reflects real world constraints back into the model and improves the quality and usefulness of the model. The ADA approach strongly favors use of XML technologies, particularly for core business transactions. This is a natural consequence of using the XML centric IDIOM Decision Models to manage the validity and state of the core business entities. The other IDIOM products including IDIOM Forms, the IDIOM Decision Manager Workbench (including the Mapper), and the IDIOM Document Generator are similarly XML centric. When these enabling products are being used to manage the full life cycle of operational transactions, there is the opportunity to persist the data as XML inside the database rather than mapping it into a fully normalized table/column structure (note that the data within the XML is normalized there is no implication here that data should be anything other than normalized). When this occurs, there is a significant reduction in the number of tables required; each table saved reduces development effort and accompanying overhead. And for the sake of clarity, modern DBMS more or less seamlessly transition across the table/column and XML boundary, so that queries can address nodes within the XML in similar fashion to database columns. Project Size In the ADA approach the development follows different paths depending on the presumed size of the target application. ADA as currently practiced by IDIOM essentially divides projects into smaller and larger systems. The larger system approach provides a framework for coordinating multiple smaller systems that is, smaller developments are used as building blocks for a larger system. The ADA approach scales to even larger systems only though building out communities of collaborating larger and smaller systems. The idea of building very large monolithic systems is not something that IDIOM promotes as a commercially sound development approach. For the sake of clarity, a larger system in the above discussion might extend to entities/0.5-2 million lines of code. A smaller system is likely to be an order of magnitude smaller. Multiple smaller systems that achieve the same functionality as one larger monolithic system can reduce the development risk factors by large margins. This approach of decomposing larger systems into multiple smaller systems is an important ingredient in reducing development time, cost, and risk, and improving business agility. T Capers Jones 3 has documented this effect over 10 s of thousands of projects, and provides overwhelming evidence that size is the basis for an exponential growth in cost, time, and risk. Agile Development Agile development describes very closely the culture and practice of an ADA project. The development of the decision models as described above provides deliverables very early in the project that are business accessible. In fact, it is imperative that the decision model outcomes are 3 Copyright IDIOM Ltd 2015 Page 6 of 25

7 specifically validated by the SMEs as and when produced. This should occur within the first few days of the project, and continue on a regular basis throughout the development of the decision models that is, for the life of the organization. As noted above, the decision delivery cycle should provide the early deliverables for both small and large systems alike. At this early stage, we might also consider initiating development tasks as required for Technical Risk Management. We should expect to maintain the shortest feasible cycle time for the remainder of the development. While this is important to reduce the risk of divergence from business expectations it is also driven by our antipathy to producing throw-away documentation. If we are to avoid the need for interim documentation, the requirements must be captured in small, just-in-time bites and immediately delivered and reviewed. If larger cycle times were to prevail, the requirements for each would grow and some form of interim requirements capture would likely be required. For a smaller development, which is likely to also use other IDIOM technology enablers like IDIOM Forms, the Mapper, and/or the Document Generator, business accessible functions should continue to be developed and delivered on a similar timeframe; that is, every few days. This means that the business should be prepared to review and respond to the evolving system functionality multiple times per week. For larger systems, which typically include a higher proportion of native dotnet or Java development, the delivery cycle may start with one or two deliveries per month, reducing to weekly releases as the project progresses. As a rule of thumb, larger ADA projects should be delivering weekly or better for at least one quarter of the elapsed development timeframe prior to UAT, and throughout the UAT process as required. By way of example, IDIOM recently produced an underwriting tool for a major insurer that was developed by a single developer working daily with the SME a few minutes daily review and consultation, with the rest of the day spent developing. A few weeks effort led to the first operational deliverable, and the process has continued since with outstanding success for the customer. On a larger scale, a million plus line-of-code system was developed for a multi-billion enterprise where the only requirements documentation was a solution overview and data model attached to the contract prior to starting funded development. The project delivery cycle started at 3 weekly intervals, reducing to weekly, with the interim requirements derived through workshops and confirmed by . The project was delivered to UAT ahead of schedule. Architecture Architecture, both application and technical, is an important project task, no less so in an agile development. The ADA approach, as with the rest of the development concepts, attempts to simplify the architecture overhead. For the small projects, ADA makes no architectural imposition because a small project is deemed by definition to fit within the customer s existing architecture/infrastructure. For larger projects, the architecture may be imposed by the existing corporate infrastructure and associated standards, or a new architecture may need to be proposed. In the case of the former, ADA Copyright IDIOM Ltd 2015 Page 7 of 25

8 expects the project to adapt to the existing architecture. In practice, the IDIOM technology easily adapts to the various infrastructure architectures that IDIOM has found across our customer base, although from time to time, minor upgrades do need to be made to the IDIOM products to facilitate this. IDIOM only uses the large proprietary stacks (e.g. Oracle, IBM) when these are already in situ. When a new architecture is required, an ADA project will usually select from the small set of practical industry standard architecture patterns and promote that pattern without undue modification. Typically this means selection of a Microsoft stack, or an Open Source stack with minor product variations in the various layers selected from the most popular open source projects. The application architecture (as distinct from the technical architecture) is addressed in larger projects by the Solution Overview document. The Solution Overview is a document that provides a how it will work narrative in a business readable form, supported by reference to technical details in the form of point documents and the results of risk reducing proof developments as they arise from the Technical Risk Management activities. As with the system itself, the Solution Overview will evolve, and will at its completion reflect the rationale for the various design options that have been implemented. Team Structure An ADA development team is a multi-function team that works together in a way that is modeled more on the Special Air Service (SAS) than the traditional Armed Services. As with the SAS, any of the IDIOM team are capable of leading a development, and in all cases there is only one team lead for any ADA project. The team itself is comprised of different resources who are seconded into the team by the team lead as and when their particular skills are required. Architectural and technical recommendations tend to be democratic and weighted to the most experienced/skilled team member, but there is only one decision maker the team lead. Testing Testing is an important function within any development approach. In an ADA based approach, it takes on additional importance. The testing phase is used to reverse engineer the requirements into test scripts, user manuals, and explanatory documents as required. There is a considerable amount of testing that occurs naturally within an agile development because of the rapid delivery cycle and the high user involvement with each iteration of the deliverables. However, this testing is compromised and should not be relied upon for the final deliverable. Firstly, it is usually forward looking or sunny day testing it only seeks to address what is required or expected and tends to ignore minor, non-critical, and negative processing issues. Secondly, both the developers and the users involved are likely to be positively engaged and want the system to work. They have a vested interest in positive outcomes that may color their perceptions and allow the minor/negative issues to be overlooked. Therefore, a fresh, new perspective is required to complete the testing cycle and ratify the deliverable. As we have outlined, the entire narrative documentation to date may be limited to a Solution Overview, a data model, and some point technical papers around areas of risk (and these may be little more than s). In fact, the detailed requirements are actually documented in the form of the current system image. Copyright IDIOM Ltd 2015 Page 8 of 25

9 Because there are no detailed requirements documents per se, the tester is required to reverse engineer the system image to derive testing and user documentation. The system image, supplemented by direct consultation with the developer, is the subject of a discovery process that has the benefit of casting fresh eyes across the entire deliverable, searching for any inconsistencies or incompleteness. Because this deep review process can identify gaps in the implied requirements that may cause minor additional development, the testing process should begin within the development process itself, typically in the last third of the development cycle prior to UAT. The same discovery process can be used to derive test scripts, user manuals, and any other end product documentation that may be required. This means that the tester should also be qualified to produce the draft manuals et al so that the process of acquiring deep knowledge of the deliverable can be reused as efficiently as possible. Project Management Lightweight project management has been adapted to reflect the extreme agility of the ADA approach. For small projects, project management is easily managed through regular briefings with the sponsor, supported by updates as required. For the larger projects, the paucity of definitive advance requirements statements means that there is little structure around which to build a traditional project plan. Also, the rapid cycle time and evolving requirements are not easily configured into a Project style plan. IDIOM therefore adapts a simple progress tracking spreadsheet to the specific needs of each project. The core components, including decision models, technical risk management tasks, and the various infrastructure add-ons (eg web services, database development, authentication, etc), are listed in columnar format. A development time/cost assessment is made for each listed component that indicates how long it will take to reach the first visible iteration. This iteration will be the minimum core sunny day functionality only. IDIOM refers to this iteration of the deliverable as Iron. The Iron stage deliverable represents only a percentage of the actual development of the deliverable, and this percentage can be variable. As a rule of thumb IDIOM considers the Iron standard to be 40% of the overall effort to deliver the component for natively coded components, and 60% for auto-generated components. The tracking spreadsheet will then manage and track the remaining development percentages for each component by reassessing it at various growth stages with the following as an example. Note that the stage tests in the following example table are iteration independent. Copyright IDIOM Ltd 2015 Page 9 of 25

10 IRON BRONZE SILVER GOLD Test We can demonstrate the core process working end to end. We can demonstrate all requirements of the core process, given that we may have manually provided or bypassed some supporting and ancillary functions and data. We can demonstrate the full life cycle for all data and functions required to execute, service, and support the core function, including reference data entities, service wrappers for functions etc (this extends to the full life cycle, including delete). We can demonstrate 100% delivery of all functions and features, down to and including all validation, styling, and content of literals and messages. Content The 'Sunny Day' end to end process is in place - this proves the declared core functionality of the component. The core function is extended with links, life cycle functions for the entities involved, and related event processing, so that the 'positive' functionality is complete. Implied and 'negative' functionality is added, including validation, referential integrity, error checking, derivations, delete constraints, conditioning of screen field variations, auditing. Signoff on all detail ANATOMY OF A DECISION CENTRIC PROJECT A Small Project A small project is one which will be led and primarily developed by a single developer. This developer is usually a decisioning consultant because by definition, an ADA project has decisioning at its core. This is not so much an emphasis on single person delivery, as an assertion that a single person will personally manage all requirements elicitation and their capture into the evolving system image. This reduces requirements translation and overhead, leading to a more efficient process. The process begins with preliminary discussions between the developer and the sponsor to determine scope, objectives, and constraints. The decisioning core is identified and developed into decision models. This initial task commitment is limited in duration, from a few hours up to a week or so not more. When the initial decision models have been validated, the project is determined to be viable and the technical landscape is then assessed and the required architecture adopted. The developer expands the decision modeling and attaches various interfaces and points of integration (for example, user forms, database mappings, service interfaces) and delivers the system in short cycle iterations. When the system is usable to any degree, the tester joins the project to review the deliverables, and to eventually produce any final documentation as required. Copyright IDIOM Ltd 2015 Page 10 of 25

11 Small Project Outline 2 Executables are visible and testable by sponsor Domain Expert/Sponsor defines the request in comfortable business english 1 Requirements communication is casual, even verbal. Developer translates requirements into executables System artefacts accumulate into growing system image 3 Tester identifies + reports gaps/ omissions Finished system, test scripts, documentation delivered for UAT Developer describes system method and intent to tester System discovery process used to build test scripts and user documentation 8 Idiom Tester Test Scripts, User Documentation Copyright IDIOM Ltd 2015 Page 11 of 25

12 A Large Project A large project is one which requires multiple developers to work collaboratively to achieve the system objectives. A larger project usually requires development of natively coded infrastructure and/or integration to support the decisioning core. A larger project is therefore a multi-disciplinary project, with a major division across the XML/decision centric components and underlying natively coded infrastructure. Depending on the extent and specific technologies involved in the infrastructure development, multiple technical developers may be seconded. Again the team lead will be a decision designer/developer, because this is the core of the requirements. For the sake of clarity, all bespoke data and process requirements derive from the decisioning core, and so will be initially visible to the decision designer/consultant. Requirements that are not typically bespoke such as authentication, communications, process management, interface standards et al are typically left to the sub project team leads to agree with the customer technical representatives. If IDIOM is charged with recommending the architecture then a multi-disciplinary committee is formed and the architecture is agreed via workshops with IDIOM management. As noted, a larger project is typically managed more or less as a series of smaller projects. In order to coordinate these smaller projects, a central, shared Solution Overview and Data Model is developed and maintained for reference and use by each of the smaller projects. These documents are developed iteratively, and are prescriptive only in so much as agreed design and development decisions become binding on all sub projects. The team lead is responsible for ensuring that the Solution Overview and Data Model accurately align with the business requirements through regular review and consultation with the business. This alignment process is active rather than passive that is, the team lead is required to promote the meaning and intent of the documents to the business and educate the business as required to ensure that alignment is maintained, and to actively seek and rectify any mis-alignment. Within the overarching perspective of the Solution Document and Data Model, the various sub projects develop more or less autonomously, with regular internal reviews (at least weekly, often daily) as to progress, and less frequent scheduled reviews with business SME s and sponsor representatives as required. Progress reporting is collated weekly and updated into the tracking spreadsheet. A larger project overview is shown in the following diagram. Copyright IDIOM Ltd 2015 Page 12 of 25

13 1 6 Business Sponsor defines the system objectives and constraints 3 Solution Overview provides basis for contract Solution Overview 4a Objectives, constraints, solution options discussed 2 Solution Overview segments the solution into multiple small projects Idiom Sponsor responds with Solution Overview document System artifacts accumulate into growing system image 5b 5a Requirements executables reviewed regularly Domain Expert Domain Expert Finished system, test scripts, documentation delivered for UAT Executables are regularly visible and testable by Domain Expert 12 4b Developer partners with a domain expert and proceeds as small project Developer Developer Developer describes system method and intent to tester 7a 7b 9b 9a Tester identifies gaps/ommissions Idiom Tester 10 8 Same system discovery process is used to build test scripts and user documentation 11 Test Scripts User Documentation Copyright IDIOM Ltd 2015 Page 13 of 25

14 IDIOM PRODUCTS IDIOM Tools As you might expect, IDIOM has been fine tuning its flagship IDIOM Decision Manager product since its launch in 2001 to fully support the concepts outlined in our series of articles. In fact, the name of our company is a reflection of the importance of the business idiom, and of its relationship to both business rules and data. The idiom is the proprietary language that is used to describe the essence of any business it is used to describe its business policies, its decision making, and its business rules. And in so doing, the idiom refers to the data in context. The challenge lies in mirroring this context within the various executables that implement it. Defining and automating the idiom is the essence of our business and of our IDIOM Decision Manager product. Furthermore, the high performance SQL-XML mapping tool alluded to in the XML section exists as the IDIOM Mapper, and is in part responsible for the very high performance of many of our applications. The IDIOM Mapper generates simple SQL from an XML configuration document, and then executes a full round trip transaction cycle: From database to XML; then rules execution (multiple decision models); and from XML back to the database. All done extremely quickly, either in single transactions or in batch. The Mapper process is thread-safe and can execute in many process streams. The entire Mapper cycle is also embedded in a management application called the IDIOM Decision Manager Workbench. The Workbench is an industrial scale, ready-made batch application processor for large scale, high performance batch processes. A transaction often requires dialog with a human actor. A dialog is easily managed by building an IDIOM Form over the transaction data the same data as is available to the decision models that interpret and maintain it. An IDIOM Form includes the ability to execute IDIOM Decision Models inside the Forms experience on a large scale, field by field if necessary, to ensure a fully reflexive user experience. Finally, the transaction end state might need to be reported via one or more business documents. The stand-alone IDIOM Document Generator can be used to generate complex business documents under the control of decision models, using only Word authored text and images as additional design input. The IDIOM Decision Manager IDIOM Decision Manager is a tool for graphically modeling, testing, and deploying business decisions - without programming! A tool for the policy maker, not the programmer. IDIOM automates complex decision-making at the enterprise level, deployable as industrial strength stand-alone components. In day-to-day practice it is usually used by SMEs, or analysts working closely with them. Together they model the business policies in terms of both data and decisions (see Decision Model below) before moving on to define the underlying logic that binds them together (see Formula below). Copyright IDIOM Ltd 2015 Page 14 of 25

15 The decision logic and data are usually modeled together in a single combined process of analysis and definition. The data model and the decision model share the same context awareness, with current-context and context boundaries visually highlighted at all times within the palettes. Testing of the models (or any part thereof) is available at all times within the development palettes themselves; full regression testing (incl. model answer differencing) is available in the adjacent Test Executive (not shown). Deployment as 100% generated software components is fully automated and without fingerprints. IDIOM Decision Manager decision palette showing a Decision Model Example above is a small but real model drawn from a city council implementation of policy that calculates financial contributions to be paid by property developers. The problem domain is decomposed using a mind mapping approach until we reach the atomic units that we call decisions (rounded boxes). Copyright IDIOM Ltd 2015 Page 15 of 25

16 This decision model and the adjacent data model (left hand panel above) are demonstrably aligned and integrated through shared context - validating and strengthening both. The data model defines the problem domain at rest; the decision model defines the valid state transitions. Together they completely define the required business policy. The atomic decisions provide an easy entry point for specification of the underlying rule details via the Formulas (see next). IDIOM Decision Manager formula palette showing a Formula The underlying rules details are easily captured using a Lego like drag-and-drop development approach that is more fun than playing golf according to the CEO of one of our largest customers there is no scripting or coding required to build these formulas. The rules can be tested immediately within the IDIOM Decision Manager palettes. When finished, IDIOM Decision Manager generates computer source code (C# or Java) with a single button click, to be called by any application at run-time using any of a wide variety of simple interfaces and wrappers (in-line, dll, web service, queue service, many more). And at the same time, it generates the model into business readable documentation (PDF). Copyright IDIOM Ltd 2015 Page 16 of 25

17 Key Points of Difference IDIOM s decision models do for decisions what data models do for data a powerful abstraction that makes the underlying complexity visible and manageable. The models allow internal data transformations and business rules to be intermingled within a single transaction. Business rules acting alone are severely limited in their ability to fully resolve complex commercial problems invariably, in-line data transformations are necessary to facilitate the calculate/adjudicate/act behavior of business rules. Context is continuously displayed and actively managed. Decision models that incorporate both data and rules behavior enables a further critical capability that is unique to IDIOM Decision Manager the models can be fully tested using real-world cases directly in the builder palettes. No external technology or application support is required to empirically prove the correctness, completeness, and consistency of the models. Key Point of Innovation Fundamental redesign of the traditional SDLC by fully separating the development and automation of business policy from development of the systems that support it. Use of IDIOM is effective in spawning a Business Policy Development Life Cycle that is managed independently of and alongside the traditional System Development Life Cycle. Key Value Propositions 100% alignment of systems based decision making with business policy, because the business owners have hands-on custody and control of the policy definitions actually used by the system. Increased agility and reduced business risk through business modeling and empirical testing of actual policy definitions prior to automated generation and implementation. Significant reduction in the business cost of developing and implementing automated business policy. Further reduction in software development cost, time, and risk through reduced system complexity and clear separation of concerns. Further Benefits Full auditability of policy changes, and visibility of policy implementation through the graphical models and logical English PDF generation. The Decision Manager Workbench is available to experiment with and further develop policy independently of the systems development process. Automated, robust, industrial strength deployment on any scale supported by the transaction processing application and its underlying platform. Simple injection into legacy systems leading to eventual legacy replacement. IDIOM Forms IDIOM Forms is a tool for generating web2.0 forms that embed the power of IDIOM decision models into the form itself. As the user navigates through an IDIOM Form, the integrated decision models can be executed on an element by element basis to make various business calculations and assessments; and to modify the form s meta-data. This allows the decision models to dynamically adjust the visible shape and content of the form on an element by element basis. Copyright IDIOM Ltd 2015 Page 17 of 25

18 A single IDIOM Form can be used to process complex business transactions (e.g. an insurance application, a clinical pathway, a loan application) through to closure, including such functions as validation, transaction acceptance, costing or pricing, up-selling, plus determination of subsequent workflow. The IDIOM Forms Engine (the runtime component of IDIOM Forms) is production hardened after many years use on thousands of servers throughout the NZ health sector. The deployed IDIOM Forms Engine became the basis for the NZ Health Information Standards Organisation (HISO) forms standard and is currently the most compliant under that standard. The Forms Engine is now also widely used in the finance sector for insurance underwriting and claims management globally. IDIOM Decision Tracker The IDIOM Decision Tracker is a tool to map MS Word and Excel policy documents to IDIOM decision models for full bi-directional traceability between corporate policy definitions in the MS documents and their actual implementation as IDIOM generated decision engines. IDIOM Mapper The IDIOM Mapper generates simple SQL from an XML configuration document, and then executes a full round trip transaction cycle: From database to XML; then rules execution (multiple decision models); and from XML back to the database. All done extremely quickly, either in single transactions or in batch. The mapper process is thread-safe and can execute in many process streams. IDIOM Decision Manager Workbench The IDIOM Decision Manager Workbench is a user operable platform for running decision models across enterprise databases on a large scale without the need for IT technical support. A generic batch processing platform for use by IT and business operations. A platform for the auditor, the business policy manager, the product manager, the corporate business strategy manager. An audit tool for identifying, reporting, and managing anomalies, errors, and issues of concern in any database. A simulation tool for comparing the performance of current and to be versions of any automated policy; and a tool that can modify data on the fly to simulate changes in the make-up of in-bound transactions over time A data masking tool, able to replicate large scale databases with all personally identifying details masked from its own library of several million fake identities. Relationships between identities in the underlying data can be maintained, notwithstanding the use of fake identities. A conversion tool: able to read data from one system in its proprietary format; intelligently transform it through one or more decision models; and then output it to a new system also in its proprietary format. A scale of millions of entities and hundreds of tables is easily supported. Examples of Use Copyright IDIOM Ltd 2015 Page 18 of 25

19 Superannuation Fund Administrator: Perform all period end processing, including fee s, insurances, member adjustments, entitlements, and reporting, for several hundred thousand fund members. Insurer: Compare the current underwriting policy with a proposed underwriting policy across a recent portfolio of 500,000 insurance policies to determine potential changes in the rate of referral and its attendant costs. Superannuation Fund Administrator: Run 100 s of distinct audit tests across 1,000,000 member accounts on a daily basis to independently verify the production data. City Council: Compare this year s rating policy with next year s proposed rating policy for each property in a city of more than 500,000 ratepayers to identify outlier changes in the rates actually charged. Insurer: Dynamically modify key attributes of real transactions to simulate changes in the make up of the in-bound business, and assess the impact of these changes across an entire portfolio. Enterprise Class Features Full authorization and audit controls down to the field level for all users of the platform. Seamless operation across multiple user definable environments, for instance Development, UAT, Simulation, Production. High performance, including parallel processing on a large scale across multiple machines, for instance running up to 24 Processes on each i7 class CPU, with multiple CPU s possible, each logging back to the Workbench for centralized management. Measured Performance Copyright IDIOM Ltd 2015 Page 19 of 25

20 Daily pass of 1,000,000 active pension fund members each comprising of a join of 20+ complex member related tables for a total of ~one billion rows. 10 s of Decision Models implementing hundreds of individual member tests. Alerts captured and reported daily for start of business. Run daily in 30 minutes using one i7 class processor, with data drawn from an IBM iseries. IDIOM Document Generator The IDIOM Document Generator is a tool to collect and collate Word document templates and many associated text fragments (called blurbs), and to assemble these into complete documents under the control of a decision model. The templates and blurbs are checked for style consistency when sourced. A schema defined XML document is generated by the Document Generator that lists all of the blurbs required for a document, and any variables highlighted within them. The actual insertion of each blurb is then triggered by a decision model on a case by case basis. The decision model also populates all of the variables named in the text, so that large and complex documents can be generated automatically under the control of decision models to reflect the exact circumstances of the underlying business record. The Document Generator also allows for insertion of images and for calling bespoke programs to insert additional text or images. The Document Generator only requires standard Word authoring skills, and IDIOM Decision Manager. Copyright IDIOM Ltd 2015 Page 20 of 25

21 Service Offerings IDIOM is flexible with regards to how it provides its services. Standard development services agreements and/or license agreements can be used to provide products and services. However, we recognize that the initial capital investment implied by license purchase is contrary to an agile development approach and so we also offer the Assisted Pilot Model. The Assisted Pilot Model is a T&M based approach that is transparent in its application. It also includes perpetual, cost free licensing of any IDIOM licensed deliverable that may be included in the project and delivered to the customer. This provides the customer with source code ownership of the complete deliverable. The model also allows the options of continuing development on an IDIOM service based approach and/or purchasing the relevant IDIOM tools for internal development use. IDIOM understands the decisioning space in general and the ADA approach in particular, and can take the delivery risk through fixed price delivery if desired by the customer for ADA styled projects. IDIOM s service capabilities can be found in our Capability Statement. Copyright IDIOM Ltd 2015 Page 21 of 25

22 WORKING EXAMPLES OF DECISION CENTRIC DEVELOPMENT Examples of Decision Model Complexity Two project examples from 2014 that dealt with large scale complexity. Defined Benefit Scheme Defined benefit schemes are contracts between a pension fund and its members. They are renowned for their complexity and long-life. We have recently codified the trust deed for one large fund with a membership in the hundreds of thousands. The underlying trust deed is more than 30 years old, and the complexity of the entitlement calculation has grown considerably since it was first drafted. A member s entitlement under the scheme can change on a daily basis; as you can imagine, the current entitlement is keenly sought on a regular basis by the members as they try and manage their affairs, both approaching and post retirement. This calculation is currently done in batch in a legacy system. Defined Benefit Scheme The calculations require large amounts of source data - including 30 plus years of working hours and salary history, with many rules applied at source to adjust for historical data anomalies (e.g. an employment terminated with no record of that employment ever commencing); A long standing customer can have 40 or more separate periods of employment service, as a new employment service period commences with any change in service: role, employer, payroll, part time work, leave without pay, temporary incapacity, permanent disability, deferral from the scheme, leaving the scheme, re-joining the scheme, etc. with each requiring special treatment in the calculations; There are 40 or so intermediate calculated values that contribute to 30 or so benefit entitlement calculations, all of which incorporate many historical changes in the scheme over its 30 year life (e.g. prior to a particular date a calculation is undertaken in a certain manner with a certain set of rates applicable, which is then changed a few years later, etc.), so that some benefit calculations have 4 or 5 of these historical changes inside each calculation method; The result is calculations that are multi-layered, starting with several high level components and cascading down through multiple layers of sub-calculations so that some individual calculations have more than 100 discrete sub-calculations within them; Each calculation or sub-calculation might need to include indexation by either daily or quarterly CPI in different circumstances e.g. just for a certain period, or from the date of a certain event forward or backward in time, or for a certain event only when other specific conditions apply; Some calculations require dividing period-of-service base data into multiple smaller time-boxes based on externally supplied dates (e.g. Scheme Date, Calculation as at Date, 20 year service threshold date, 65 th birthday), with different calculation rules applying in each new time-box. Copyright IDIOM Ltd 2015 Page 22 of 25

23 The legacy system batch process that calculates the current scheme entitlements takes >48 hours to run; furthermore, these are only top-up calculations that simply calculate the latest adjustments on the assumption that all prior calculations are sound. The original intent behind our involvement in this project was to confirm the assumption about the soundness of all those prior calculations as used by the existing system. This meant recalculating the full 30+ years of contributions and entitlements from original source data, and reconciling the results with those that were calculated by the multiple legacy systems that had been used to manage the fund over the years. While we can now safely say that the current fund calculation is correct, there was a surprise result at the conclusion of our effort the new full 30+ year calculation runs an order of magnitude faster than its current legacy system top-up only equivalent. In fact, this calculation speed, and the fact that each member is processed within a discrete transaction, means that the calculation can now be performed in real-time as well as in batch. The downstream benefits of this are significant. The fund can now provide modelling of future changes in real-time so that the member can use the calculation for financial planning purposes; and/or, the fund can provide a service that provides advance information to members regarding future regulatory changes, scheme changes, etc.; and/or the fund can perform financial forecasting and affordability testing for the investment managers of the fund. Payroll Audit and Remediation The aim of this project for a NZ Government department was to build a transaction to: Reprocess all termination payments for people terminated between 1/4/2004 and 27/10/2011 to verify that they had been paid in accordance with the NZ Holidays Act 2003 To achieve these aims it was necessary to build an employee level transaction that: Used the IDIOM Mapper to retrieve the required base source data from the Payroll System Databases (e.g. Employment Details, Allowances, Payments Made, Leave Taken, LWOP Days etc.) Constructed an intermediate data structure suitable for the analysis Calculated what the payments should have been and compare these with payments made Produced a report with references to the individual inputs and the intermediate calculated structures to provide a detailed audit trail to support remediation payments (or the lack thereof). The complexities involved in this project included: ~10,000 members terminated in the period, with total remediation pay outs of several $$million Poor discipline and procedures in the underlying payroll systems resulted in varying data quality, including inconsistent and irregular data (e.g. leave taken following termination) Data structures and database keys changing over time as systems migrated Running different calendars for different parts of the country Copyright IDIOM Ltd 2015 Page 23 of 25