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

Mark Norton  13 June 2010 06:21:50 PM

This post is the third in a series. We are now at day 39 of our 80 day challenge and counting. It has been 12 working days since our last post.

You can read Part 1 here and Part 2 here.  

To recap, our goal is to use the Idiom Decision Centric Development Approach™ to build an industrial strength platform for investment and superannuation funds management that incorporates a substantial decisioning component as 'business content' within the platform. This decisioning content is the basis of outstanding business agility. It also allows decision models to be shared across many application instances on the one hand, and allowing bespoke customer decisioning on the other.  

Data Architecture

As noted the previous posts, we first scoped the study area, and built a conceptual data model. This model has been expanded to form the basis of the Plex generated database. It also provided a conceptual framework to guide the development of the decisioning schemas being developed by the Decision Designer. So the Plex and Idiom components are building up independently from a common conceptual framework.

The Plex defined database has now reached a degree of maturity with regards to both the Customer and Administration functions, and the underlying funds management functions. Database size is in the order of 42 tables. The decision models have not yet been formally reconciled with the database. This is now a function of the next timebox.

Decision Models

Good progress has been made on the decision models. Next week these models will start to be integrated into the underlying platform.

The Contributions Model implements a broad set of Australian legislative requirements. It is a complex model that was iteratively developed over 2-3 days by the Subject Matter Expert (SME) and Decision Designer who formed the decision modelling team. Testing has been done and the model is now ready for integration as a robust and complete implementation of this legislation.

The Benefits model has been extended to include rollovers, cash-out, retirement, and preserved/non-preserved/restricted no-preserved money.

The Unit Price Validation model is now 95% complete.

The SFP Unit Pricing model has been built to support Super Fund Unit Pricing but is still pending some design input at ~50% complete.

Unit Trust Fund Pricing - model established for unitised and interest investments.

Unit Trust Client Pricing - not started.

AML CTF is now under construction.

Rebates is 95% complete.

These models are now being developed and maintained directly by the SME, with Idiom consultants providing support as required.

Process Models

The XSOL Process models continue to be built out with the end Customer, capturing various requirements to be fed into the Plex development and reconciled with the Decision Models.

Plex Models
We have completed the core components of the system, and completed two iterations to upgrade the UI approach for these. In the first iteration, Plex patterns were introduced which overlaid the system with menu and navigation metaphors. In the second iteration the UI paradigm was altered so that child windows open in the context of the parent window, and once open, they remain live to the parent, changing context as the parent does. For instance, if I open a window for customer addresses from a customer list window, I see all of the addresses for the selected customer. If I select a new customer, then the address window automatically updates to present the new customer's addresses.

At the same time, the Customer and the Vendor have both adapted to the power of agile development, and the number of design requests has risen sharply in the last 2 weeks, with the total number of specific documented requests doubling in that time. This is the critical time in an agile development. In a traditional development, the system boundary is defined in the inception stage, and is rigidly enforced subject to change requests. This introduces all of the downsides of the requirements phase as documented here. Instead, the agile approach uses a combination of functional targets and timeboxes to create boundaries. This means that the development team needs to start applying constraints where the customer does not otherwise see any - the system boundary is defined and applied dynamically. This is now occurring.

The Vendor has now started this process of drawing this dynamic requirements process to a close. At this time we transition into the consolidation phases of the development. The last major change in the customer and administration area will be to introduce a new over-arching 'Involved Party' table to provide a generic entity to represent a system party. This follows a doubling of the number of roles to be tracked by the system over the past 2 weeks, and an increasing realisation that relationships between and across the parties are valuable and useful. This is a normal feature of an agile development - it is fair to say that the customer has been able to grow their perception of their requirement in line with the evolving system. This is a major benefit of the agile approach - provided that the process can be slowed and drawn to a conclusion gracefully and within the development fiscal parameters.

Following this phase the Plex development will focus on integrating the Decision Models, and then consolidating all of the functionality. After that, system level testing will become an increasing focus. But please note, this is not testing as you find in a traditional development, for 2 major reasons:

• The decision models have reduced by an order of magnitude the overall system complexity, and these have each been independently validated and tested within the 'decision development cycle'.
• The Plex generated code per se does not need to be tested. We are left with functional testing of the system as a whole.

The Plex development has progressed apace in advance of the decision models by focusing on the standard components - the parts which are not business differentiators, like security and menu systems, reference data tables and support systems, and client administration. These parts are being poured as 'electronic concrete', but with a model driven tool like Plex driving it, it is still very agile. By the 11th June, the sole Plex developer has extended the client and administration subsystems, comprising 42 database tables and 76 application screens, and released 2 distinct and progressively more complex iterations of the entire system, with one more major iteration now planned for the coming week.

Now the Plex development is moving into the area of back end support for the core funds management area. This will be reconciled with the evolving decision models in the next timebox, and adjustments made to the database and/or decision model schemas as required.

39 days and all is well - see you in a couple of weeks.

You can now read Part 4

• Comments [0]