The Journey

towards a world class rapid application development / deplyment platform…

Prospects, customers, users, developers, designers, disbelievers oftern ask me, “how the heck did you guys build your platform and what was the thinking and the processbehing it’s evolution?”

This post is an attempt to try and answer that question;

Fundamentally, the expanz team believe the software development world needs to adopt a paradigm shift similar to the manufacturing world’s transition from a factory model to an assembly line model.

The gains in quality and reductions in development cost and effort would outweigh those in the manufacturing world as no physical materials are actually consumed during production – everything is abstract.

When object oriented technology was first invented, this was its promise, but I think you’d agree OO has miserably failed to deliver on that promise.

The risk with our approach was that the assembly line was simply unachievable as many large companies have spent considerable effort and money towards achieving this goal, although indirectly. There are several known and unknown (don’t you what you don’t know) issues, such as performance, missing platform/language features etc that could prevent the software assembly line from becoming reality.

Attempting something this radical would require a non standard and carefully monitored process.

Plenty of unknowns and risks… Would performance be good enough?

We decided to have a crack and are glad we did.

The solution of course must be scalable. We threw away the stateless model (I can hear you sceptics down my broadband connection) and embraced a stateful application server model, for both ease of end user development and more importantly performance. We built a [stateless] web service facade, a load balancer that only load balances on login (session creation) and an application server to house our code. Off to a nice start…

The core design patterns were envisaged and used in a lightweight walkthrough. Next, code was filled out and simple apps were built, starting with a non-persistent calculator.

Then we added persistence and complex persistence – relationships. This was an absolutely crucial phase of development. To achieve a true assembly line pattern, we could not use explicit collections. There was no way a class could ‘ask’ a child (a many in a 1-many relation) to iterate through itself in a reusable way if held a declared collection of that class. We had to design it so that all relationships were implemented as a single declared instance. This was probably the key single breakthrough that allowed us to continue towards our goal. Every object/class had to satisfy both single instance and set operation requirements.

Since progress was good and all theory still held up, we decided to upscale our experiment as far as we could. We decided to build an ERP system – yes, we are gluttons for punishment.

This would prove our platform, from a utility, performance and code reduction perspective (we achieve code normalisation), as ERP systems are generally considered rigid. We could, through an assembly line paradigm, provide complete customisation at very low cost/effort to an ERP customer – exact fit ERP, now there is a foreign concept.

As development of our assembly line paradigm continued, another opportunity emerged.

Due to the embodiment of the best practice rule of complete separation of the presentation layer from the functional layer (e.g. abstraction), it was hypothesised that multiple client designs and technologies could simultaneously access a single server without any server modifications.

This would mean that a Windows form, a browser form, a Flash form and even a mobile phone could all access the same [server] functionality at virtually zero development effort – only the cost of designing the UI.

We set about abstracting the communications protocol into a set of interfaces, and implemented those for Windows Forms and WPF, those being two technologies we were familiar with and both based on c#. Apart from a steep learning curve for some of the WPF features we required (and a general lack of available expertise) it was ultimately successful.

Next target was a mobile device, as this would be useful in the ERP system for warehouse operations. The MS .NET Compact Framework (CF) has matured to the point where it was only a few days of effort to port the full Windows Forms plumbing to the CF. We rapidly enhanced the set of Interfaces we designed earlier to cope with device-specific hardware such as cameras and barcode/RFID readers.

Finally, to overcome deployment issues (the latest .NET installed on a client PC was a caveat) we decided to embrace the Adobe Flex/Flash technology. We found some local expertise which was commissioned to adapt the standard algorithms and interfaces into ActionScript – the Adobe language. We ultimately had the need to put this into production (after some simple prototypes) for a property inspection and reporting automation system we built on top of the ERP.

We also required a handheld (mobile) device to do barcode scanning and printing for EDI orders (as a full production quality module) which was successfully developed and deployed into large Australian supermarkets and retailers.

All the while, no server code changes were required for any platform-specific technology…