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

Mark Norton  4 August 2010 03:59:44 PM

This post is the fourth in a series. We are now at day 77 of our 80 day challenge and counting. It has been nearly two months since our last post (sorry, we have been seriously busy!). It now seems obvious that we are not going to squeeze our final delivery into the 80 elapsed working days that we set ourselves, although we are still under budget for the total resource effort that was anticipated in our Part 1 post (which was an approximation based on 4 people times 4 months). Note that this includes all project resources, not just the developers.  

So is this failure??

Such a conclusion would be unfair to the agile approach - two things have happened that could reasonably justify some extension.

Firstly - some scope expansion, indicated by the doubling of the database tables in the last period. The angel customer is so impressed with productivity that new complexities are being included in the scope, and even now some requirements are still being accepted for development. This is the power of 'agile' - requirements remain open virtually until transfer to production. Contrasting this with a traditional approach, we can easily imagine that a formal requirements phase alone could have taken this long for a project of this size. In a later post we will publish the actual system metrics for comparison across approaches.

And secondly, the running system has been demonstrated to prospective new customers, and sales negotiations are now under way with several. Note that the system was sufficiently sophisticated and operationally complete at day 63 for 'real-world' sales demonstrations to take place and obtain genuine customer buy-in, resulting in ongoing and positive negotiations re system purchase and/or investment.

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

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 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 stable, but still subject to completion and related changes. The database design size is now in the order of 86 tables, more than double the size at the last post. Our original post anticipated 100 tables, a guess which looks increasingly accurate.

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 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 to the application requires only that the Plex developer makes 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.

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.

We are now in the process of transitioning the early stage decision models onto the latest version of the database. This is a natural step in the methodology:

• The decision models were originally built against the context provided by the conceptual data model, rather than against completed data design (because the data design did not yet exist).
• The schemas developed and validated by the decision models were then used to guide and validate the evolving physical database design. This data design was also fleshed out by other external and/or decision driven functional requirements.
• Now that the data design is at a high stage of completion, the decision schemas need to be re-aligned to the final database design and the decision models tweaked to align with any new terminology and data structures.

This final step is now underway. So far, our experience is that the logic defined in the decision models that were built in the early stages of the project is very stable, with most changes being driven by schema (more 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).

Plex Models
We would categorise the Plex development as now entering a 'closing phase' in that new requirements and requirements changes are being actively suppressed and the design is rapidly stabilising.

There is still a reasonable amount of work to do to complete integration with the various subsystems and external interfaces, some of which have only recently been confirmed in a design sense. Amongst these is a subsystem for inbound capture, management and auditing of legal documents, and an equivalent system for generating, managing and auditing outbound standard letters and other formal documents. These two subsystems will also demand a significant workflow component.

Despite the work still to do, we expect the system to be available for QA this month.

77 days in and we are behind our initial target delivery period - but with new customers engaged at this early stage, and more sophisticated functionality already built into the system, the vendor remains pleased. See you in a few of weeks!

You can now read Part 5

• Comments [0]