The Plumtree Group - dartV3

Electronic Document & Records Management and Routing System

At the start of 2011, The Plumtree Group decided to redevelop their flagship product "Dart" from scratch.
Whilst the current incarnation still recieved great customer feedback, it was build using old technologies and was never designed to be as heavily customized for each customer as it is now, and as such needed a fresh start.

I was initially selected as the lead developer for the project, and later on took over the project manager role as well.

I proposed that the project should comprise of a "core" framework and several "drop in" modules. The "Core" was responsible for discovering and "injecting" the modules as and when they were "dropped" into a specific directory, as well as managing the flow of data between all the modules. The modules should be split into two types; "Base" modules, which would handle the more fundimental activities such as data source access and error logging, and "Normal" modules, which would handle the "normal" business logic and functionality for specific concearns, such as security and record management.

The key difference in this approach to the more convential projects is that none of the individual modules would hold any references to each other. Whilst they could "demand" a minimum version of another module be present, they couldn't actually directly reference the objects or methods within each module. This allowed to us instill a deep sense of seperation of concerns, thus allowing us to modify any part of the system quickly and efficiently, without affecting any other part at all. It would also allow us to generate customised versions of any aspect of the system without having to maintain a seperate code branch of the entire product.

Another benefit of this approach is that initial deployment and the application of future upgrades or additional modules would become extremely simple to perform; the user would simply drop the new modules into the specific folder, and the system would automatically detect and inject them into the system; no reconfiguration of the application would be required at all.

Also, it meant that several front-ends could be implemented for the same system, all sharing the same instance.
At the time of release, the project included a web-based GUI, an administration MMC interface, a WPF client GUI and a dedicated mobile device web GUI.
With them all sharing the same instance of the "core" framework and ancillary modules, we would be able to keep commonly-accessed data in memory and access it from any end-point application, making data access speeds much quicker than if it had to be read from a database, but without the memory-overhead seperate interfaces would have introduced.

After discussing the proposal with the rest of the team, we decided to create a small prototype to both test the viability as well as the overall speed of the planned framework.
With a simulated load of 1,000 concurrent users and a data load similar to those seen on our clients at the three-year mark, the framework outperformed the existing system by 350% in terms of content delivery times and request processing times.
With the idea proven to work, we developed "dartCore" and several ancillary modules that would form the basis of the new Dart product.


The product has been rolled out to several of The Plumtree Group's key customers and has proven to be an instant hit with them.
The speed of the new product has been the main talking point, but as and when updates have been released, or clients have purchased additonal modules their IT support teams have also been impressed with the simplicity in how the system is upgraded - greatly reducing the time they needed to invest in supporting the product.

At the time of writing, we are currently planning the re-write of several other of The Plumtree Group's products so they are based upo the "dartCore" framework.