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

Mark Norton  14 September 2010 10:53:22 AM

This post is the fifth and last in a series. We are now at day 100 of our 80 day challenge. It has been just over a month since our last post. The system has now been released to UAT, and while some adjustment and corrections are inevitable, the system is more or less complete. We have now exceeded the 80 working days elapsed target that we set ourselves. However, in terms of total development effort, our Part 1 post anticipated that the project would require 4 people for 4 months (say, 4*4*20 days to give 320 resource days). Total development effort to date is slightly over 300 days, so in terms of resource effort we are under budget at this time. By the time we go through UAT and into production, we are likely to slightly exceed this resource budget.

Within this budget, we have assimilated significant scope change and expanded the customer base.

The system is significantly more complex and comprehensive than was first envisaged by anybody involved, including the vendor and the angel customer. Fortunately, a scenario of increasing complexity is easily managed in an agile development environment.

And because the the system was in a semi-operational state very early in its life cycle, it was able to be presented to multiple prospective customers. As a result, a second customer is now also funding development activity, and is in negotiation to fund a significant 'next phase' extension of the system to cater for large scale industry funds.

You can read the earlier blog posts here: Part 1  Part 2  Part 3  Part 4

To recap, our goal was 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 in the previous posts, we first scoped the study area, and built a conceptual data model. This model was 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 were built up independently from a common conceptual framework.

The Plex defined database is now complete at 93 database tables, which compares with our original (Part 1) guesstimate of 100 tables.

Decision Models

A generic component has been implemented within the Plex application to dynamically integrate decision models. The Plex application simply passes a context key(s) and the name of the required decision model to the generic interface, and the new component does the rest. From a Plex perspective, adding a new decision model invocation to the application requires only that the Plex developer implements this simple call.  

From the decision model perspective, the decision designer has a little more work to do. Besides actually building the decision model, they need to map their decision schema to the database using the Idiom Mapper. Then they need to publish the mapping and the decision model into the new Plex component for the decision model to become operational. The actual decision model itself can be replaced at will (between calls if required).

Following the execution of the decisioning process, the component notifies the Plex application that made the call that the decision model has completed. All decision updates are posted directly into the database for subsequent use by the Plex application. This approach can be used synchronously or asynchronously - note that some decision models may run for an extended period, for instance, hours if they are processing all members of a large fund; others may process a single entity, in which case the execution time will be reduced to millisecond timeframes.

The final set of decision models includes:

Capital Contributions
Calculate taxes and over cap warnings.
Asset Trading
Calculate the realised gains per certificate and summarise data per investment and pool  
Pool Pricing
Revalue all investments (calculating unrealised gains ‐ pre and post 12 months) plus tax calculations
Calculate interest accruals income bearing investments fees
Produce summary records for pricing events, pool price history, and including data from the pool cash file
Calculate fees
Benefit Payments
Calculate benefit components and tax amounts
Produce summary payment details
Warnings of insufficient or illegal components.
Pension Set Up
Calculate min / max amounts, relevant numbers, and life expectancy

Our experience has been that the logic defined in the decision models that were built in the early stages of the project is very stable, with most subsequent changes being driven by schema (mostly terminology and a lessor amount of structural) changes. Only a small number of decision design changes have occurred because of a more advanced understanding of the problem domain. This tends to emphasise the value of decision modelling as an early stage project activity - the requirements as captured by decision models are quite stable within the overall set of project requirements because they do represent the 'essence' of the business - they are not inherently mutable. Understanding the decision model at this early stage also clearly assisted with formulating the later stage data and functional requirements, while at the same time segregating out considerable complexity - this simplified the overall development, with the effect of reducing cost, risk, and time at an exponential rate (according to Capers-Jones).

The above models have generated >150,000 SLOC of C#.

Plex Models
The Plex development has produced 103 user interface panels, mostly combined maintenance grids with sub-grids managing multi-valued details.

Total SLOC is >1.89M lines of code, including generated C++ client side presentation and C# back-end programs.  

Analysis and Conclusion

The project team ended up being 3 and a half  people rather than 4, including 1 Plex developer, an SME (also acting as Decision Designer), a process/systems analyst, and some part-time resourcing from Idiom decision consultants to give a total project resource cost of just over 300 person/days, including inception and startup. The total is expected to be less than 350 resource days by the time the system in production. This team was also split geographically across 2 countries and 1000 miles of the Tasman Sea.

The team has built a complete business system, including CRM, unit pricing, fund and superannuation account management, asset trading modules, general ledger, document management., and statutory reporting. The current function point count is >20,000fps.

In terms of development productivity, the project has produced one complex (multi-grid) user transaction per Plex developer day. Taking the whole resourcing cost into account, the project has demonstrated a sustained productivity ~10 function points per resource hour for the full development life-cycle.

The development agility made possible by model driven development has accommodated significant adjustment to the scope and complexity of the system as originally envisaged. Note that no formal requirements phase was undertaken - the detailed requirements we developed 'just-in-time' according to an over-arching set of concepts that were agreed in the inception stages of the project.  

Business agility has been retained through the decision models. These decision models implement customer specific requirements (for instance fees and pricing), regulatory requirements (for instance contribution cap and tax calculations), and industry best practice (for instance, benefit calculations, reporting, realised gains).

Each of these decision models can by dynamically adjusted and replaced into the system without interruption to the operational system, so that changes in customer requirements, regulation, or business practice can be 'managed as content'. Changes in system capability and user interaction remain in the domain of a traditional SDLC change, albeit with the speed and agility offered by the model driven development environment.

For more information on this project and the approaches used, please feel free to call us. I can be contacted as follows:

Mark Norton | Product Director | IDIOM Limited | Microsoft GOLD Business Partner |
Office +64 9 304 1199 | Mob +64 21 434669 | After Hrs +64 9 817 7165 |
22 Dundonald Street, Newton 1021 | PO Box 67-067, Mt Eden 1023 | New Zealand |
Email mark.norton@idiomsoftware.com | Skype Mark.Norton |

www.idiomsoftware.com | Business rules for business people

• Comments [0]