In part 3, I discussed using storyboarding as a way to help industrialize the software development process.  Business users interact with software 100% of the time through a user interface.  If we as software developers focused our effort developing storyboards for a business software application, this would result in a complete specification of what the business user wants without writing any code.  It also dramatically reduces the tremendous gap between requirements (i.e. intent) and executables (i.e. what is delivered).  Further it industrializes the way we develop software from a mostly trial and error approach to one that is repeatable and predictable, thereby reducing project/product risk substantially, reducing the cost of the project and minimizing schedule overruns.

 

This storyboard approach is not novel as it is tried and trued in the film industry.  Whats novel is that it is rarely done in the software development world.  As software developers, we spend so much time under the technical covers of applications we forget that business users do not care, the business user is only interested in their data as represented in a user interface and what they can do with that data.

 

Imagine if we had a catalog of storyboards (i.e. models of user interface screens, not implementations) based on vertical business industries, such as a CRM application for manufacturing or a supply chain application for electronics distribution or a workflow application for order processing or  Lets say we had a catalog of a thousand storyboards that we could flip through and select storyboards for our customers for a specific business application.  We could go even further by saying that these storyboards contained metadata that describes the user interface elements that make up the storyboards.  Based on the selected storyboards for a particular application, we could code generate a specific technology implementation of those storyboards, from the storyboard metadata, which means transformed into an actual user interface implementation for a specific targeted technology.

 

Pipe dream?  Maybe.  On the other hand, I see the current way we are developing software as a pipe dream or at the very least it requires many development iterations spending lots of effort and money to produce something that does not necessarily meet the business users requirements.  It currently takes too long to develop a commercial grade business application of any size or complexity.  Remember the dot com era? Customer got fed up en mass with our software industry that set unrealistic expectations of what software can do.  Customers will likely get fed up again, sooner than later. Corporations are also fed up spending millions (ok, billions) on software development projects with seemingly no end in sight and at a 50% failure rate you would think there would be a revolt.  If I was a customer, I would say the failure rate is unacceptable.  Some would say the odds are better in Vegas.  Something is going to give.  It is this process that is going to drive the industrialization of software.

 

User interface storyboards contain metadata that describes the user interface elements in a non-implementation specific way.  As mentioned before business users do not care about which technology, they care about how fast and cheap the implementation can be done.  Since an implementation of a storyboard (or set of storyboards) could be code generated, the selection of which implementation technology could be based solely on what IT infrastructure exists already in the company, thereby leveraging the companys current assets.

 

While we dont have a catalog of storyboards today, it would not be that difficult to assemble since most if not all the user interface screens, from an implementation view, exists today in the tens of thousands of applications that are already in the market, albeit some better than others. We could abstract these implementations into storyboards, including the metadata that describes the user interface elements, and start assembling a catalog of user interface storyboards.

 

Lets assume we can do that for just a moment.  Lets say we have chosen 50 storyboards out of a catalog that represent a particular business application and we have code generated an implementation of those storyboards into a technology specific implementation.  How do we hook those user interfaces up to data?  How do we do transaction processing?  What about workflow?  Business logic?  And why do we abstract at the user interface layer? These are topics for my next post in this series.