Moving IT spend from Maintenance to Innovation – Part 2
Last week’s posting talked about optimizing IT spend in the area of maintenance so that spending on innovation could be increased. So this week I am going to blog a little bit about what we are doing at Aspeq in the innovation space, with a particular focus on custom application development.
Unlike many larger companies with similar technical responsibilities, Aspeq has an IT team of only six people in total. These people are responsible for keeping a network infrastructure not totally dissimilar to an airline (40+ offices) up and running, and also developing and maintaining several quite complex line of business applications.
Being in the business of regulatory assessment – the fees chargeable to our customers (typically those in flight training, under taking builder licensing or transportation licensing) are often set by the government and for the most part are much lower than equivalent unregulated industry assessment charges. So in simple terms, the amount we are able to spend in order to deliver what are often complex technical assessments is much lower than comparable private industry focused assessment providers like Prometric.
This reality means that by necessity we have to get a lot more “bang for our buck” and can’t just go out and buy all the latest development tools like Microsoft Visual Studio Team Services. Instead we have a blend of commercial tools (like the lower cost Visual Studio Professional Edition) and open source tools and libraries. Surprisingly this isn’t all bad – in fact in many cases it turns out to be quite the opposite.
For project management, testing and source code control (which allows us to keep track of different versions of software we write as we write it) we use open source solutions Redmine, NUnit and Subversion respectively. Redmine provides many of the features that the more expensive VS Team Services would provide, and NUnit is generally considered to be at least as good if not better than the less mature Microsoft unit testing equivalent. From a source control point of view, Subversion is multi-platform and certainly more reliable than the Microsoft stable Visual Source Safe.
From an architectural and staffing perspective, we have also gained some advantages by using open source libraries. Although we are in effect a “Microsoft Shop” using Microsoft technologies for software development, my personal view is that often the best Microsoft developers come from the competing J2EE technology background. J2EE developers are used to doing things “the hard way” rather than using wizards and accelerators prevalent in the Microsoft tool suite – and in my experience they actually understand what is “under the hood” a lot better than those who haven’t had to code things from scratch.
The architecture we have chosen as a result of the J2EE influence of some of our development team is based on Microsoft’s MVC (Model View Controller), which whilst new to Microsoft has been successfully used by other platforms such as Mac, J2EE for some time. We’ve also chosen to use an open source ORM (allows us to get information easily to and from the database in “object oriented” form) technology called nHibernate – another port from the J2EE environment.
Using nHibernate and a spin-off technology called fluent nHibernate has allowed us to almost entirely focus on designing and building the application – with the database and plumbing to access it all taken care of automatically via set conventions. The time saving concept is that of “convention over configuration” and is used in popular rapid application development environments like Ruby on Rails.
The irony of this, is that Microsoft has recently released a technology called “LINQ to Entity” which seems likely to provide most of this functionality in several years time. At the present time it currently requires extensive configuration and so is considerably less productive than the open source equivalent. This means using fluent nHibernate has already provided some productivity advantage over the equivalent commercial offering.
On the downside, we have found some of the open source libraries to be a little bit buggy or incompatible with each other. Originally we looked at using the S#arp Architecture which combines together things like Fluent nHibernate, xVal (for client side validation) and Castle Windsor and Microsoft’s MVC. This was an ideal combination and probably something that Microsoft will be likely to deliver in their upcoming .Net 4.0 and Visual Studio 2010 release – but otherwise not available as yet.
Unfortunately, the S#arp architecture was built on beta versions of the previously mentioned open source libraries and simply stops working when libraries were updated to production releases. So in the end we had to build our own framework based on these technologies, although being open source we were able to use re-use much of the open source S#arp architecture code to do this. This has increased our initial effort getting the project underway quite considerably, but enables us to manage risks associated with open source library changes or incompatibilities more easily.
On top of these technologies we are also employing a test driven development approach, with 3 week delivery sprints culminating in a demonstration to our business users which we have found to be more effective that attempting to get them to understand detailed requirements documents. The application we are building (a redevelopment of an existing application developed by external software companies for us) is also tested each time developers check in modifications by using Cruise Control to automatically run unit tests, and alert all of our developers if any tests fail substantially increasing reliability.
So what is the end effect of all of these technology choices and approaches? On the down-side, using MVC and nHibernate requires more experienced developers staff – “property assignment” programmers just aren’t up to it. MVC also takes more time to get set up, and limits what can be easily achieved within a user interface compared to Microsoft’s Forms approach. The stability and currency of open source libraries also needs to be monitored with care and has potential to derail a project schedule if not managed.
On the plus side, the application we are re-developing is considerably more testable in an automated way than its predecessor. This means it is more reliable and that testing cycles for updates are much shorter than ongoing development. The choice to bring development in-house and into a single project rather than a series of outsourced enhancements , use an agile development approach and a more product ready architecture has also led to a reduction in overall costs to one third of previous application development costs.
The verdict – open source development can a higher level of technical skill and and risk, but if managed carefully can lead to substantial cost reductions and increased productivity for in-house software development projects.
Uncategorized | seand | 
November 8, 2009 10:33 pm
Subscribe