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

Mark Norton  25 May 2010 04:59:20 PM

This post is the second in a series following our post on the 8th of May. We are now at day 27 of our 80 day challenge and counting.

You can read Part 1 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.  

The Idiom Decision Centric Approach™ involves the following development phases and responsibilities:

• A domain scoping study that identifies the Sponsors core IP and identifies the set of extended features and functions that are required to support this core IP. From this study an assessment of candidate decision models and supporting host application technologies can be made.
• Development of the core decision models to the point of tested completeness.
• Development of underlying host applications and/or integration components.
• Integration and system testing.
• Handover and user acceptance testing (UAT).

There are various impacts of the approach that affect the working relationship between the IDIOM project resources and the Sponsor:

• The approach is very short cycle and transparent to the Sponsor – progress can be reviewed on a continuous basis. The decision model development is usually performed by a Decision Designer working closely with the Sponsor. The Sponsor is responsible for providing subject matter ‘know-how’, and later, valid use cases to validate that the decision models correctly implement that know-how.
• When the decision models are sufficiently complete, the Decision Designer uses the knowledge gained to drive the expansion of the underlying host application. Business agility is being wired into the underlying platform by this approach.
• When the overall solution is sufficiently complete, it is passed to the system test team, who will test the Application at arm’s length (note that the decision models should have already been tested in the first phase for the 3C’s – completeness, consistency, correctness).
• When the Application passes its system testing, it is released to the Sponsor for UAT. The Sponsor should plan for an independent UAT with assistance from the Decision Designer as required.

It can be seen from the above that the Idiom approach is an iterative cycle of development and testing that focuses on the core IP first, and then builds out to include the supporting infrastructure.

As an aside, there was a great series of tweets yesterday that provide an analogy for the above. Firstly James Taylor re-quoted a source from Shell - 'Once you pour electronic concrete, it is hard to get out'.

To which Idiom replied:

Tweet 1 - Concrete builds a very stable house; and

Tweet 2 - Just don't cast your furniture in concrete too - decisioning is like furniture, U never know when the wife wants to move it!

In the above application, the Idiom Decision Models are furniture in the CA-Plex generated house.

So where are we up to?

Data Architecture

As noted last post, 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. In our analogy, the furniture is being built with an understanding of the rooms and overall plan of the house, but we are not yet mapping the furniture room by room.

Decision Models

Work has been done on the Contributions Model, Benefits Model, Unit Price Validation Model, and SFP Unit Pricing.

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 was built from scratch for both Withdrawal and Death Lump Sum payments in one day. By following the systematic approach of deriving the schema inputs and outputs by first laying out the rules that need to be implemented, the team were able to build and unit test this decision model in 4 hours. In future there should be further additions to this decision model when other Benefit types are to be supported by the application, but these additions should be easy to add by copying the common pattern of decisioning that was implemented for the Death and Withdrawal benefit payments.

The first cut of the Unit Price Validation model was also built within a day, again by first white boarding the rules work-flow to get a candidate schema and then constructing the decision model. This decision model will expand as knowledge of the area builds up and is incorporated - a decision model is designed to grow and change!

The SFP Unit Pricing model was built to support Super Fund Unit Pricing. This decision model is 1 of 4 decision models that will need to be developed for Unit Pricing. The others being Unit Trust Fund pricing, Unit Trust Client pricing and Super Fund Client pricing. The Super Fund Unit Pricing model is currently being tested but is also likely to grow.

Points to note:

Idiom's agile approach to schema management allowed the team to make changes on the fly as they were writing the rules so at no point were they treading water waiting on other system components (like databases, screens, and interfaces).

Idiom's user interface and easy to teach concepts enabled a mutual knowledge transfer  between the SME and the Decision Designer, so much so that after 4 days the SME is now proficient in developing rules and making changes as testing
progresses. This has implications for training courses - maybe they should be dropped in favour of on the job training - far more productive.

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

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 20th May, the sole Plex developer had developed the entire reference data and client subsystems, comprising 21 database tables and 61 application screens. These have been loaded up as an application and reviewed by the end customer - inside the last 2 week timebox.

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. An additional 14 tables have been defined to date.

27 days in and all is well - see you in a couple of weeks. You can now read Part 3 here.

 

• Comments [0]