In my last post, I discussed a model for sizing and estimating effort for building software applications.  This model worked reasonably well based on some assumptions.  One assumption was that customers actually saw the need and value in spending the time documenting use cases and going through an estimating process.  That in itself is a hard thing to do.  Another assumption was that this was not a net new, never been done before, application by the development team or using brand new technology to build the application.  It also assumes a development team that has worked together on more than dozen projects.  Just like any team sport, it takes several times playing together for the team to gel.

 

So what does this have to do with on-demand applications?  Everything!  Because the reality is that most customers dont understand the need for software sizing and estimation.  Also, the application being developed, indeed is somewhat net new and maybe with new technologies and the fact that most software teams are nothing more than assembled bodies, thrown together to get a project done in the shortest time possible based on who is available at the time.  The irony is that the project will likely cost (much) more and take (much) more time because the customer and the thrown together team fail to follow a sound engineering process for properly sizing the software and estimating the effort required to build the application.

 

Enter on-demand application generation.  After Googling the phrase, I think some explanation is required to help set the context of what I mean.  On-demand means I can get it now or in short order.  Application Generation means that I can use a higher level of abstraction to define what the end application is supposed to be without resorting (or at least minimizing) source code programming.

 

Sound too good to be true?  Lets take the company I used to work for as an example.  We had a core, very experienced, software development team that worked together on roughly 25 projects over a 4-year time frame, specializing in application integration projects.  Translation - we had a very high performance team focused on one type of application development, which meant that we leveraged very specific technologies and code libraries (some built, some acquired) and used a number of integration design patterns to mostly assemble our integration applications.  Then we developed that higher level abstraction into an on-line drawing tool that allowed us to define the integration application to be built and then we built an application generator to take this definition to assemble and code generate the final application integration.  This system is called BRIDGEWERX and is designed to generate application integrations on-demand.

 

I think our company is/was unique because we understood the business value of having a high-performance software development team where management did not view programmers as simply bodies that could be plug and played together with some wild expectation that somehow this was going to work.  You dont just assemble a NFL football team overnight and expect to win the SuperBowl the same season.  Ludicrous!  Yet our business leaders expect just that.  Its just software isnt it?

 

With respect to the estimation piece, using on-demand application generators dramatically reduces the effort required as most of the effort is up front, defining the application to be built using a high-level abstraction modeling tool as opposed to manual labor source coding.  Oh to be sure, there will always be some level of custom programming, but the point is that 80% of it can be generated and the other 20% is highly focused specialized work.  In the case of our application integration generators, the only custom development is in developing an interface to the application to be integrated if one could not be bought off the shelf.  The rest of the effort was simply using the modeling/drawing tool to define the application integration to be generated.  This could be measured in hours and days instead of weeks and months (or years) with the traditional manual labor approach.  Even more important is that this approach is more predictable and repeatable and therefore, dramatically reduces risk, particularly for the customer.  This is the beginning of the industrialization of software.

 

Next post we will look at BRIDGEWERX components to see how it qualifies as an on-demand application generator.