Using the Idiom Decision Centric Development Approach™ to build a brand new system with outstanding business agility in 80 days (Part 1)

Mark Norton  8 May 2010 06:38:40 PM

Idiom is currently working with a vendor in the funds management/superannuation space. The ‘greenfields’ project will be building a  system to manage the entire requirement for investment and superannuation funds managers in 4 months elapsed with 4 people - approximately 80 days.

Many of the underlying requirements in this space originate in regulation – investment fund and superannuation management is a highly controlled activity with high potential liability for fund administrators and trustees. The vendor’s goal is for a highly agile, low cost system that is also robust and scalable – sufficient to address all ends of the administrator market (funds from hundreds of millions to hundreds of billions of dollars, and each servicing from hundreds to millions of fund members).  

The Idiom Decision Manager and Idiom’s ‘Decision Centric’ design approach were chosen to provide the agility needed to address both the changing regulatory and customer specific requirements within a single system image. Idiom provides the ability to externally capture and verify the complex regulatory requirement, which can then be supplied to all client administrators across the industry as a pluggable component. A by-product of addressing these core, variable requirements with the efficient, short cycle Idiom development approach is that it reduces the size and complexity (translation: reduced risk, cost and time) of the underlying platform build.

The target market currently uses several underlying technologies, including MS Windows at the lower end, with the iSeries popular at the higher end. Idiom is a model driven approach that can generate code for both the MS and Java based platforms equally.

The underlying systems development is being addressed with the CA-Plex tool, which is also a model driven generator that covers this range of platforms, so that these two model driven tools can work together to address the full requirement with 100% generated code.  Plex offers superior development performance for highly scalable and robust systems. But it is a software developer's tool, so Idiom is used to allow the systems and funds administrators, and customers, an ability to independently manage the core decision making within the system, resulting in outstanding business agility within an industrial strength systems platform. Idiom Decision Models will dynamically plug into the Plex generated systems infrastructure (and perhaps others as required).

The purpose of this post is to highlight the highly efficient requirements process that we are using to feed these two systems generation models.

The traditional requirements process drives a high degree of uncertainty into the downstream development process at high cost (as described in ‘Requirements and the Beast of Complexity’). Such an approach would normally see a sequence of increasingly detailed transformations starting with the external requirement (in this case the regulation text itself plus a smaller set of customer specific requirements) being interpreted/transformed into an abbreviated form for customer communication, high level analysis requirements from an industry SME, more detailed process specs for handover to developers from a technical BA, and eventually into the development models for system generation. At this early stage of the development process, the range of documentation tools encountered already includes Word, Excel, SmartDraw, Visio, Dezign, XML Spy and XSOL, plus the system generation tools Idiom Decision Manager and Ca-Plex.

 The scale of the initial application is expected to be in excess of 100 database entities/tables, with 10 or so significant decision models anticipated within the process activity set.

The greater proportion of the requirements are derived from Government regulations, which typically change at least annually. Additional customer specific decision making can be found in areas like fees and rebates, which are generally well defined within each customer(s) existing operation.

These externally sourced requirements on the input side, and the Idiom/Plex models on the output side, are the significant and mandatory inputs and outputs of the overall development process. The analysis challenge is to take this known and relatively stable set of source requirements and transform them into models within the Idiom and Plex tools in the most efficient way possible. By definition, any additional documentation that is produced during the analysis and development process is not a required output and represents a cost.  

The following guidelines were adopted to make this process as efficient as possible. They are presented more or less in the order of use, but bear in mind that later tasks might begin in parallel with earlier ones – that is, all activities will be occurring in parallel at certain points of the project, albeit with regards to different requirements within each stage. The sequence and priority of the requirements is an important aspect of the approach in its own right. For instance, development of core reference tables and such predictable functions as customer management and user management can be fast tracked right through to the Plex modeling and systems generation phase while the SME is still analyzing the regulatory environment in detail. In fact, the first dozen tables and all supporting user transactions were all completed in the first 2 weeks while the high order requirements (ie the scope) were and are still being developed. This high degree of parallelism is important to an over all development process that is expected to take only 4 months elapsed for 4 people - 'A complete new whole-of-business system in 80 days'.

High Order Requirements
The highest order requirements are the cornerstone value propositions that define the scope of the system. Such high level processes are typically domain but not necessarily client specific – in this case, the initial high order value changes would include such processes as valuing funds, valuing units, valuing client holdings. These high level value transformations in turn drive a need for investment trading on the one hand, and member transacting (investments and redemptions) on the other. And as the range of participating entities grows, so does the range of events that will require system responses, and so on through the range of development activities. These ‘scoping’ requirements, including high level processes, relevant subjects (data), and events, are typically defined by the sponsor, in this case the vendor.

Primary Role: Sponsor plus SME's

Tools: Any (Word, Smart Draw/Visio, Excel)

Government Requirements
All of the regulatory requirements are captured in their source form (ie use the regulation text directly), avoiding translation as much as possible. References to Government site URL’s are listed to provide a map of regulatory requirements. There are cases where the SME's experience indicates obvious flaws and inconsistencies in the regulatory requirements (which are after all, just another narrative requirements specification that can only be deemed accurate by definition), so the SME provides an additional narrative commentary to assist with the correct interpretation of the natively formatted regulation texts. The Government sourced text and the commentary will be consumed directly by the Data, Process, Idiom, and Plex model developers.

Primary Role: SME.

Tools used: Word/Excel for the additional commentary.

Customer Requirements
All of the customer value transformations are captured in their source form, avoiding translation as much as possible, with reference directly to customer documents. There are cases where customer references and practices are at variance with each other and with system assumptions, and so the SME provides an additional narrative to assist with the correct interpretation and positioning of the customer requirements. The customer sourced text and the commentary will be consumed directly by the Data, Process, Idiom, and Plex model developers. The areas of customer differentiation are highlighted and extracted as target Idiom Decision Models.

Primary Role: SME.

Tools used: Word/Excel for the additional commentary.

Data Architecture
The data architecture is the technical foundation of the entire project. It provides the core definition of terms and the inter-relationships between the terms that will be used in all requirements and modeling activities, including decision (Idiom) and systems models (Plex). While the actual database will be defined in Plex, and transactional XML will be defined as part of the decision models, the database architecture is needed early in the requirements cycle to provide the underlying glossary and to underpin all other requirements aspects, including any narratives - it is needed before development of most Plex and Decision Model components. This 'glossary' is critical to avoiding the beast of complexity as described by ‘Requirements and the Beast of Complexity’.

Therefore we should provide a high order data view of the target domain in relational model form as soon as key terms become known as part of the high level scoping, and certainly before it is complete and before the external requirements sources have been fully identified and marshalled into the project.

Primary Role: Senior Plex or Idiom developer – both of these tools are data driven, and data analysis is natural to these developers. Plus SME support. The process BA should participate in order to take-away and incorporate all data analysis concepts and terminology into the process models.

Tools used: Dezign.

Decision Models
Decision models are carved out of the overall requirements using a number of criteria.

1.        Complexity: Highly complex areas of decision making should be separated out from the underlying platform to reduce the network effect that their inclusion would cause to the overall project cost, risk, and time – simplify the underlying system by identifying and isolating complex calculation effort. The appropriate boundaries for a decision model can be found in this Decisioning article.

2.        Customer Specific: A decisioning requirement that is logically ‘owned’ by a single customer has by definition a many-to-one (and in some cases many-to-many) relationship with the underlying system(s). It should be extracted and developed as a discrete model.

3.        Temporal: Regulations regularly and predictable change over time – many are specifically time delimited. All such requirements are many-to-many with systems, and should be isolated as a discrete unit of work.

4.        Value Transformations: The normal criteria for decision model development also apply – is there a critical value transformation occurring that is logically controlled as content by a stakeholder – if so, it is a candidate decision model.

The decision models have two components: the fact model that is described using an XSD; and the decision model described in Idiom. The fact model should use the data model as a reference glossary, but it should not be bound by it. The fact model is derived independently according to the needs of the decision model.

Each tested fact model is reconciled back to the data model to validate and extend the data model as required.

Each decision model is included in the process flow diagrams as a discrete activity.

Role: Decision Designer, SME.

Tools used: XML Spy, Idiom Decision Manager.

Process Models
Process models are developed through a process of assimilating and collating the other requirements categories as they are identified:

·        The decision models must be placed within larger processes that deliver data and respond to decisions made, identifying more events and data as a consequence;

·        All events must be responded to by a process – events carry and affect data, leading to more data and processes;

·        All data (entities and attributes) must have a CRUD cycle that lives in a process, identifying more events, data and processes;

The process model evolves out of the ongoing analysis, providing a requirements canvas that binds everything in a multi-dimensional framework. The process map will use the data model as a glossary, and together with the data model it becomes the primary driver for the Plex systems model.

The XSOL Process mapping tool as a very effective repository based tool for capturing process flows and events.

The Idiom icon is implemented into the XSOL activity types, and is inserted into any process map that requires it. The nominated decision model is documented as the process activity name. This simple expediency clearly separates the Plex and Idiom roles within the overall system and avoids any tendency to intermingle components of decision models with other process activities. Without the clarity and discipline that the tightly bounded decision models introduce to the process model, this intermingling is easily done with detrimental effect.

Plex Models
The Plex developer is directed by the Process Models, the Data Model, and the Decision Models, Non functional requirements are negotiated directly with the sponsor as required, but only if there is any doubt, or where choices need to be made. Styling and other aspects of image and presentation are delivered natively in the first instance, and then modified by applying style patterns during the project as the sponsors view of the evolving system becomes clearer. The Plex generated system is presented to the sponsor more or less in 2 week timeboxes. The sponsor controls additional presentations to the customer as required.

15 working days in and progress is on track - 2nd timebox this week.. Stay posted for future updates!

You can now read Part 2 here.

• Comments [0]