This last post in the series is to describe a few more details around the Storyboard Designer application I am building.  Storyboard Designer is targeted at Power Users and/or Business Analysts (BAs) to enable a quick way to design and construct custom business user interfaces, which will in turn become business applications. The application will allow for the design and construction of workflows, business rules and data access associated with these user interfaces.  This is done so in a storyboard fashion similar to what has been successfully done in the film industry for over sixty years.

 

Whats different about Storyboard Designer than other storyboard type applications?  From a marketing perspective it is targeted at business Power Users and/or BAs tasked with defining the requirements and specifications for a custom business application, including the UI, workflow, business rules and data access.  The idea is that requirements become specifications as defined (read: modeled) by the BA using the designer.  Since we are using XAML, the resulting specifications become the implementation.  Key point.

 

Storyboard Designer has a drawing canvas that will allow the organization of businesses and business applications.  A Power User can drag and drop UI components onto a canvas to build a user interface in XAML.  Storyboard Designer will offer catalogs of composite UI parts that are commonly used in business applications, plus the capability to reuse complete user interface definitions for common business objects like Invoices, POs and any other set of forms for that matter, built or purchased, all XAML.

 

One design goal is to ensure the BA can define (read: design) a business application using Storyboard Designer without writing any code.  Or at the very least meet the 80/20 rule.  Another goal is to provide an intuitive drawing tool that will allow the BA to specify (and as a result, implement) a business application in the shortest time possible.

 

Toolboxes of components will represent real world business application constructs, for example, an invoice form, people interacting with the invoice form in a workflow, invoice form business rules and invoice form data, all need to be easily specified (i.e. drawn) on the canvas.  In addition, objects need to be configured and hooked together to represent a real world business application.

 

Using XAML, we can more easily come up with a 3D virtual world that represents these objects in a way that dozens or even hundreds of user interface screens (plus associated roles, workflow, business rules and data for those screens) can be easily navigated to on the canvas, as thumbnails.  Clicking on any thumbnail will zoom the object to screen for editing.  Those that have played with the workspace zoom in Expression Interactive Designer will know what I mean as an analogy.  XAML will provide, layering, zoom capabilities and levels of transparency to show the connections to the various objects without the screen real estate becoming overwhelming or cluttered.  Look at how Google Earth or Virtual Earth is displayed essentially on one canvas using layers and zoom.  AutoCAD works in a similar way.  Storyboard Designer will implement similar concepts except we are looking at a map or CAD blueprint of a custom business application from a 3D drawing perspective.

 

Over the coming months I will put together a prototype of Storyboard Designer based on the specs described in this series.  I will come back to this topic when something is built.

 

The purpose of this ten part series was to discuss industrializing parts of the software development process we use to design and construct business software.  Storyboard Designer is my small contribution to industrializing software.  I have been in the software development business for 15 years and one conclusion I have come to is that the state of the art of developing software today is still trial and error most of the time.  Further, rarely does what we build meet what the business user actually required.  This is the semantic gap between requirements (i.e. the intent of the business application) and the executables (i.e. the ruin-time business application).  Talk about lost in translation!

 

Storyboard Designer provides the capability for business Power Users and/or BAs to easily draw business applications using a 3D visualization tool with the output being the actual executables for a custom business application.  Not only does the tool close the large semantic gap between requirements and executables, more importantly the tool can be used by the very people that know everything there is to know about their own business and what the business application is supposed to automate.  As a result of these tool capabilities, the time frame for designing and constructing business applications is dramatically reduced and on its way to becoming a predictable and repeatable process for delivering business applications that actually meet business user requirements.

 

Lets see if I can make this real

As described at the beginning of this series, I have a specific requirement for a Storyboard Designer application.  The specific requirement is to industrialize some level of the software development process used to design and construct business applications. The rational is that the end-user of a business application interacts with software through a GUI 100% of the time.  Therefore, provide a designer tool aimed at Power Users and/or Business Analysts (BA) who can quickly storyboard user interfaces, workflows and data access in the shortest time possible.  Storyboard Designer is not a traditional developers tool, but rather a visualization tool that can be used by a Power User and/or Business Analyst (BA) to quickly build scalable and robust business applications.

 

Think of it this way, senior management at FedEx, in the book, , realized that the people actually performing the work on the shop floors knew their business processes inside and out.  And more importantly, knew what most of the solutions were to the problems they were encountering using traditional business applications and consequently, the business processes they imposed.  As a result of senior management listening to employees in the trenches, FedEx reengineered their way into an incredibly successful business.  In other words, they were the first to industrialize the way packages were shipped and delivered for a specific market.

 

Remember the introduction of FedExs online package tracking software?  So simple that anyone with some degree of being able to navigate the internet could use this tool.  Thats why it became #1.  Another example, closer to home in the software world, is MS Access and Excel, which are reasonably complicated software, but yet Power Users and BAs have developed an entire subculture of business applications running organizations today.

 

With respect to Storyboard Designer, a Power User and/or BA (the people that really know the business application in question), can create their own business applications in the shortest time possible.  The goal is to quickly create or reuse user interfaces, (composite controls and complete UIs from catalogs), plus being able to visually hook up the UI to a data source or workflow, with or without business rules and all without writing any a single line of code.  Is it possible? 

 

From a marketing point of view, all that is required is to put a usable storyboard designer tool in the hands of the people that know how their business works so they can build their own custom IT automation applications to suite their specific needs.  Just like how they build sophisticated Excel applications and Access database programs today, except I am hoping much easier using Storyboard Designer.  Thats the level of abstraction I would like to achieve.

 

As discussed in this series of posts, I came to the conclusion that XAML would be an excellent language to not only build a Storyboard Designer, but also have the output of the Storyboard Designer produce XAML as well.  XAML can be used to declaratively define user interfaces and workflows that run on WinFX without any further interpretation.  In other words, once compiled, it can be run directly on the OS.  This is very powerful.  Even more powerful is that fact that XAML is public specification and therefore portable language format that can easily be exchanged with our XAML enabled tools.  This means it is possible to create catalogs of real user interfaces and workflows that can be shared amongst people.  The specifications become the implementations using the designer tool.  This dramatically reduces the gap between requirements (i.e. intent) and deliverables (i.e. executables) that is so prevalent in the way we design and construct business software today.

 

Storyboard Designer will be a visualization tool in which Power Users and/or BAs can draw their business applications on a canvas using toolboxes of objects that they can drag and drop on the screen.  Objects will represent UI, workflow, data access. people and businesses all connected together and can be viewed all together.  This is a key design goal.  It is in someway like traditional architectural blueprints in the construction or manufacturing industry.  Think AutoCAD for designing business applications. 

 

So doesnt Cider, Expression Interactive Designer (which I am still evaluating), SharePoint Designer offer this already?  No, all of these (low level) tools require highly skilled developers and designers to be productive with these tools.   Storyboard Designer is aimed directly at the Power User and BA for an organization.  We are raising the level of abstraction in the designer tool itself so that a Power User and/or BA with minimal training or expertise can productively build their very own business applications.

 

Next post will describe some of the design details of Storyboard Designer and then we will wrap up this series of 10 posts.

In this series of posts, I describe a real problem in the software development process of designing and constructing business applications.  Not only is the design and construction process trial and error, (i.e. not predictable or repeatable), there is a tremendous semantic gap between describing requirements (i.e. intent) and the resulting deliverable (i.e. executables).  The reality is that business users interact with software 100% of the time through a user interface.  Thats it.  Business users dont care about technology.  They care about getting their customized business application designed and constructed in the shortest time possible for minimal cost (including TCO) and perhaps more importantly, does exactly what they envisioned it do to.

 

Having designed and constructed software for business users over 15 years, it seems that using a storyboard designer application to define user interfaces descriptions and business workflows is one way to help industrialize the software development process.  Further a catalog or library of pre-built storyboards with corresponding workflows, would allow a business user to choose from a catalog a set of storyboards that would assist in defining their specific business application in a short time period.

 

After more research described in the previous post, it seems that completely abstracting user interfaces is still unrealistic given the immaturity of language standards and tools. XAML as an eXtensible Application Markup Language looks very promising for describing Windows user interfaces and workflow.  Since the reality is that the majority of business applications are targeted for the Windows platform, XAML appears to be a great way to quickly define business user storyboards that can immediately be run on XP and Vista.  XP and Vista can execute compiled XAML (i.e. C# code) on their run-time platforms with WinFX installed, and render the user interfaces and execute the workflows on the business users computer screen.

 

There are a handful of XAML applications and tools on the market that may provide an environment for quickly defining Business User storyboards.  As discussed in the last post, we are going to start to look at Cider and Interactive Designer, both from Microsoft and targeted at different audiences.

 

Cider is used inside of Visual Studio 2005.  Anyone that has used Visual Studio WinForms Designer knows how quickly one can define user interfaces.  However, using traditional WinForms, the problem is that the user interface description is tightly bound to the code-behind.  Cider on the other hand, uses XAML to define the user interface and is completely separate from the code behind.  The fact that Cider is embedded in Visual Studio means you can hook up your XAML with any programming language and other components, all within the IDE.

 

However, the quick synopsis is Visual Studio 2005 is a full blown Integrated Development Environment (IDE) and while fine for me as developer, it may cost too much and will be too complicated for a Business Analyst or Power Business User to rapidly define a business user storyboard.  Also Cider still presents a relatively low-level toolbox full of discrete controls, whereas I was hoping to have a library of common composite controls and even fully defined user storyboards (like an invoice storyboard) as catalog items to browse, select and edit.

 

While Cider is great for an IDE and directly targeted at developers, I was hoping to have a higher level of composite controls and catalog capabilities.  Also by raising the level of abstraction, I want a simple storyboarding application that is purpose-built to rapidly define business user storyboards that a Business Analyst or even a Power Business User can quickly define, including composite controls and cataloged items (i.e. completed storyboards) to select from.  This is the main goal of my storyboarding application.  Perhaps Cider can assist me in building this application.

 

We will come back to Cider, but first we will take a quick look at Microsofts Expression Interactive Designer which just released as its first CTP.  Next post.

Last post we discussed several different XML markup languages for user interface definition looking for a candidate language for designing and constructing storyboards or at least assist in building a simple storyboard designer if no suitable storyboarding applications exist.  I hinted that I found a candidate.  It looks like XAML is good language candidate.  A concise overview of this technology can be read in a recent Forrester article called, WPF Will Dominate Rich Client Development.  Carl definitely gets it.

WPF stands for Windows Presentation Foundation which is Microsofts new user interface presentation technology that runs on Windows XP and Vista through WinFX runtime components. eXtensible Application Markup Application or XAML is the design-time language that is suitable for defining and construction user interfaces and workflows that are separate from code-hind (e.g. C#) as this is the code interface separation point, sometimes referred to as the plug-in interface. That means the user interface and workflow definitions are 100% portable and are distributed through a standard plug-in package (i.e. XAML).  XAML can be shared between XAML design-time applications without any translation cost or loss of fidelity.  XAML can also be run on Microsofts new application execution environment, WPF for business user presentation of the user interface and WF for run-time workflow execution.

 

One very interesting paragraph in the article is, The key is that XAML is a description of the user interface, not an abstraction of the user interface.  This is a subtle but critical distinction.  Other XML-based user interface (UI) languages, such as User Interface Markup Language (UIML), have attempted to describe the common capabilities of multiple UI technologies or even devices, and in order to do so, they must abstract the specifics of a given platform into a common generic format.  Inevitably, something gets lost in translation. XAML makes no claim to universality; it describes Windows user interfaces.

 

Telling statement lost in translation.  While I was thinking of having my storyboarding application generate multiple user interface implementations for different platforms as a goal, it now seems unrealistic.  The reality is that most business applications are written with a Windows user interface, which ultimately is my target audience.  The fact that XAML describes a design-time Windows user interface description using an XML markup language that is completely separate from code-behind is a key technology trait required for toolability which is one of the key concepts behind why XAML

 

Carls article further states, picture a prototyping tool that could be used by usability specialists to rapidly prototype and test designs. Authors note: hey, thats my idea! Users could also consider defining web server based process flows and integrations in a business process tool and then easily handing off specifications for the interfaces of individual services to a programmer who will populate them in Visual Studio.  Interestingly enough, it is no surprise that business workflows can also be defined (just recently) using XAML in Windows Workflow Foundation. 

 

Next post we will explore a number of designer applications and tools for rapidly defining business user storyboards using, or can output XAML.  First we will look at Microsofts Orcas Cider as a CTP XAML designer in Visual Studio 2005 and the first CTP release of Expression Interactive Designer (aka Sparkle) which is a standalone product.

In part 5, I discussed a vision for a catalog of storyboards that represent user interface screens, business processes and the metadata that describes these storyboard definitions.  For example, storyboards are descriptions of a user interface i.e. they contain no technology implementation details, but rather metadata descriptions of the user interface elements.  This metadata can be used by code generators to generate a technology specific implementation.  As discussed in this series, a business user interacts with the user interface 100% of the time and does not care about the technology implementation or the technical details, the business user just wants their application ASAP and for a minimal cost.

 

Storyboarding in the film industry is used to minimize requirements risk and maximize production efficiency.  Storyboarding in the film industry models the complete film in a very short period of time and cost.  The design of the film is complete up front and then the actual construction of the film is an implementation of the storyboards i.e. film rolling, sound rolling, lights, actors, action!. The software industry could learn from the film industry.

 

Lets put the concept of a catalog of business user storyboards aside for the moment and focus on the tools and languages that are available to design and construct business user storyboards.

 

As a quick reference check, lets look at a storyboard tool that already exists to see if it meets my requirements.  A company called Caretta has produced this fine storyboarding application.  While I think this is an excellent storyboarding tool, it has no code generation facilities or even the ability to output a definition of the storyboards in any standard format.  This is unfortunate, as this storyboarding application would have met most of my requirements.

 

After more research, I could not find any storyboarding tools that meet my requirements, so we need to take a step back and look at some language standards for defining user interfaces.  I found a good reference to start from, XML Markup Languages for User Interface Definition.  There are several possible candidates to choose from.  AAIML, AUIML, XIML, XUL, XMAL, UIML, UsiXML, DIWG, XForms, and on it goes! 

 

It is amazing to see how many XML markup languages there are specifically designed for defining user interfaces.  It also is amazing to see what various stages each standard is at on its quest to becoming a real standard.  The process is slow and lengthy. I wonder if the electronics engineering world went through the same arduous process of becoming an industrialized engineering discipline. 

 

At one point in the electronics world, (70's) it seemed to all converge around the invention of the 14 pin DIP as a standard plug-in or interface that allowed chip manufactures world-wide to package their circuits in a standard package and distributed through a catalog.  Today, there are millions of different circuits on these chips in the market world-wide, all offered through standard plug-in packages.  This is a good example of "technology" industrialization where a standard interface is highly beneficial to the industry overall.

 

Ok, now what?  I spent the last week researching these XML markup languages for user interface definition, to find a suitable candidate for designing and constructing storyboards.  I think I found one that will work.  Next post we will look at the findings.

Lets take a break from whats new in software development for 2006.  In Part 1 and Part 2 of why software industrialization, I discussed some basic concepts around what does software industrialization mean and why we need it. Software industrialization is designing and constructing software in a predictable and repeatable manner.  Software industrialization is also producing a software, of any sort, that actually meets the user communitys requirements, whatever and whomever they happen to be.  Thats it.

 

In our software industry, there is a still a tremendous gap between requirements (i.e. describing the intent of the software) and the actual software deliverable (i.e. executables).  In fact, if you look at and believe statistics, our numbers aint so good!  The reality is that, we as software developers or engineers, dont have any predictable and repeatable process for creating software and we dont get the software right the first time.  In fact, we may never get it all right.

 

I have been involved in the software development industry for 15 years and have worked for several companies both in Canada and the United States ranging from my own start-up company, that I co-founded with Barry Varga, called, 5by5Software, now Bridgewerx to the very large (Kodak, Motorola and lots in-between.  Each company had their own process for designing and constructing software.  These development processes ranged from fly by the seat of the pants to highly process controlled CMMI complete with formal assessments.  In these companies I participated in several different development methodologies including RUP, extreme programming, Agile, old school waterfall for those that remember, and a mix of pretty much everything in-between.

 

I have read several dozens of books on the subject of software engineering, hundreds of articles and attended many a conference/seminar on the subject area.

 

Based on 15 years experience, I draw a few observations and maybe a conclusion or two:

 

1. Its still the Wild West" when it comes to software development.

 

2. None of the software development processes or methodologies that I have participated in has proven that one is no better than the other. The harsh reality is that manual labor software development is still mostly a trial and error process.  Meaning we are still far away from making it a predictable and repeatable process.

 

3. I have had the good fortune to work with several dozen extremely talented and brilliant software developers/engineers, project amangers, BA's, etc., who are directly responsible for the success of the projects/products I have participated in.  It is these people that have made the difference between success and failure and had nothing to do with processes or methodologies or toolsets or programming languages or technologies.  Its all about the people!

 

4. There have been a few critical innovations of late that appear very promising for increasing the level of predictability and repeatability of designing and constructing software.  These innovations are described in a book called Software Factories  

 

5. Another critical innovation is the renewed interest around Domain Specific Languages (DSLs).  Every programmer should take the time to read Martin Fowlers most excellent paper called, "Language Workbenches: The Killer-App for Domain Specific Languages?  DSLs assist in raising the level of abstraction for developers to produce software in a more predictable and repeatable manner thats the real point behind DSLs.

 

6. All the business user ever interacts with 100% of the time is the user interface, graphical, text or otherwise.  All the business user cares about is that through the user interface they can get at, manipulate, save data in an intuitive and functional manner.  Functional manner means that the software does what the business user expects or wants it to do.  In our technical world, this maybe written as workflow or business rules or custom C# libraries, or whatever development artifact(s) represents this functionality.  However, we software developers forget that the business user does not care how it is done, or what with - when I click on this thing, here is what I expect to happen, your software needs to do that.  Its that simple from a business users perspective.

 

Point 6 will be a topic of a future post, because after 15 years in the biz, I finally get the business user.  And interestingly enough, from a programmer perspective, not getting the business user is the number one reason why software projects/products failed in 1994, and still failing today

In part 4, I discussed using storyboards to represent user interfaces that could be cataloged based on different industry verticals.  These storyboards are abstractions of user interfaces that contain metadata which describes the user interface elements in terms such as type of user interface control, size, location on screen, datatypes, etc.  This metadata can be used by code generators to generate technology specific implementations of these storyboards (i.e. into a working user interface).  Business users can select storyboards out of a catalog or library that collectively would make up their business applications.

 

One of the questions I asked in part 4 was why we abstract at the user interface layer?  Abstracting at the user interface layer into a storyboard achieves several design goals.  One design goal is to abstract the user interface definition from its technical implementation.  This allows us to choose a technical implementation separate from the user interface definition, and allows us to code generate the implementation based on the storyboards metadata.  The metadata describes the user interface elements for any given storyboard.  It also allows us to cheaply and repeatedly produce user interface implementations.  Also remember that the user interface, and the functionality it represents, is what the business user interacts with 100% of the time and the only thing the business user really cares about.

 

The abstraction at the user interface layer allows us to specify how the data will get to and from the user interface.  If we apply the Service Oriented Architecture approach where the transport of data is typically web services, then the user interface can be hooked up to any service that provides two-way communications.  Whether the data source is a so-called legacy application or a database or web service or any data source for that matter, it is a simple process to hook up that data source if it is being exposed as a web service.  SOA compliant products exist today, such as Bridgewerx Business Integrator, that can expose any data source through web services allowing us to easily hook up user interface implementations.

 

People would say that each storyboard (i.e. a representation of a user interface) is unique on a per customer or per organization basis.  This may be partially true and our storyboarding tool would have to be able to easily modify the cataloged storyboard (and its metadata) to suit a particular customers requirements.  Fair enough, but at the very least if I was asked by a business user to develop an invoice screen, I should be able to go to a catalog of storyboards where there are dozens of invoice screens that contain the definitions of an invoice user interface in the form of a storyboard and I can show the business user and have a 80% chance that one of them will get us 80% of the way there.  I should then be able to load the storyboard into a tool that in 10 minutes will allow me to modify the storyboard to match exactly what the business user wanted.  Behind the scenes, the metadata would also be modified to match the newly modified storyboard.  Then we would move on to the next storyboard.

 

In a matter of days or a couple of weeks at most, working with the business user(s), we would have completely defined that business users application from a user interface perspective and without writing any code using this storyboarding approach.  Now we are in position to code generate these storyboards into a technical user interface implementation.  Take a few steps further and our storyboarding tool should also allow us to define or declare the data source(s) that the realized storyboards (i.e. technical user interface implementation) will use per storyboard, plus declaratively define any workflow, business rules or transactional requirements we may also require.  Theoretically, we can code generate the entire solution based on this declarative or metadata approach.

 

Now that we have described a vision for a user interface storyboarding tool and the metadata automation required, lets look at how we could make this a reality.  This will be the subject of my next post.

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.

In part 2 of this series, I discussed the fact that a business user of software spends 100% of their time interacting with the user interface, yet we as software developers, spend only 10% to 25% of our time developing user interfaces and spend most of our time under the covers, buried in the technical details.  As mentioned in the previous post, the business user could care less about whats under the covers in any given software application.

 

I suggested one way to increase our software development productivity and reduce product delivery risk is to spend more time on user interface development and the interactions with the business user.  I suggested that we borrow a tried and trued technique from another industry, the film industry, and develop inexpensive storyboards, that represent the user interface screens that the business user actually interacts with.

 

While we do use some storyboarding techniques in our software development process, we dont take it far enough.  I would suggest that no code is written until all of the storyboards for a business application have been developed and approved by the business user(s).  Much in the same way all of the storyboards for a film have been developed and approved before a single frame of film has been shot.

 

I think that following this storyboarding approach (without writing any code) would dramatically increase the success rate of designing and constructing business software applications. This would remove the trial and error approach (read: major source of risk) to software development that we currently have today or at least for business software, where the business user spends 100% of their time interacting with the software.  Some might say that prototyping (in iterations) is the same approach.  I would disagree, because prototyping involves writing code and soon we are lost in the details and mechanics of writing code, (under the covers again) and increasing the gap between what the business user wants in a software application and what we think the business user wants.  Remember the business user interacts with the just the user interface 100% of the time.

 

Others would say that users dont know what they want so how can we develop the storyboards?  I would suggest that if the business users dont know what they want, then we have no need to write a software application.  While I am being a bit facetious, I also believe this to be true.  If the user requirements are so ambiguous that storyboards, even using pen and paper, cant be developed, then whats the business need for software?  It has been my experience that someone or persons in an organization knows exactly what is required, you just need to find those people.

 

So how do we storyboard what a business user wants?  First we need a storyboarding tool to do this.  In the film industry, it is still done mostly the old fashioned way pen and paper.  However, since we have a computer and the business user is the target user of the storyboards and the storyboards themselves are the representations of user interfaces and provides the interaction between the business users, it makes sense to develop the storyboards as complete (representations of) user interface screens.

 

At one point in my career, I remember working on a project where we took this storyboarding approach and developed all of the user interface screens and the order that they were used for business users, using Windows Forms in Visual Basic 6.  In fact, a few of our programmers at the time, could literally whip the forms up on the spot as they were very adept with VB6 and with absolutely minimal coding could storyboard the order of the screens while clicking on OK or next buttons.

 

The business users were ecstatic with this approach cause within a few weeks we had developed over 50 screens that represented the entire business application.  Not only did this give the business users exactly what they wanted, it also provided us with a complete blueprint of what was to be constructed.  This dramatically reduced the risk of the project failing and reduced the cost of the project because we had our complete specification.  This is one approach to industrializing the software development process.

 

Next we will explore a specific storyboarding approach that separates user interface definition from implementation.

In part 1, I discussed the exponential pervasiveness of software in our world, yet to non-software professionals (i.e. programmers), the process of creating software is highly skilled, manual labor intensive process, that is still mostly trial and error.  Due to this trial and error process, 50% of most software projects/products undertaken will fail.  How can we have all of this incredible software yet the process of creating it is still in the dark ages?

 

Throughout this blog are several examples and references of failed software projects and the symptoms of the reasons why they fail.  The bottom line is that the software development process has yet to be industrialized into a predictable and repeatable process.

 

How do we industrialize software development?  A lot has been written on the subject over the years, yet from where I sit as a 15 year software professional, none of the methods or processes suffice.  Why?  I think it mostly has to do with not looking at software development strictly from a users point of view.  For example, consider a typical business user of software who comes to work everyday and launches up their CRM application or any other business application.  What is that business user mostly concerned with?  Their data represented on the computer screen, usually in a form or graph or spreadsheet or report of some sort.  The business user wants to input, manipulate, search and see their data in a manner they can understand and work with.  The business user assumes that the data is accurate and valid when they are working with it.  And when they are done working with it that it is stored somehow and can be later retrieved exactly the same way it was stored. The business user also wants the software to work the same way every time they use it.

 

What the business user does not care about is the technology used or how the data gets to their computer screen.  They also dont care about how many hours, weeks or months (or even years) it took to make this work.  They just want their data now and in the format they want.  As John Crupi says, "Biz folks don't care if you use two cans and a string to help them get to market faster and cheaper"

 

So what does this mean for industrializing the software development process?  It means spending time on the piece that means the most to the business user which is the user interface.  Thats it.  Thats all the business user sees and interacts with.  We, as software developers, spend inordinate amounts of time learning and using new programming languages (like C# 2.0), new architectures (like Service Oriented Architectures), new development methodologies (like Agile) and new operating systems (like Windows Vista), but yet, none of this has little to do with what the business user interacts with on the computer screen.

 

As mentioned above, the business user spends 100% of their time interacting with the user interface on the computer screen.  Therefore it would make logical sense that, as software developers, we spend more time focused on this area then anything else.  Sadly, in most of the projects I have worked on, user interface design and construction is but a small part of the overall development effort.  I would say that it represents maybe 10% to 25% at most of the total effort.  I sometimes wonder why this is.  Further, we usually use words (as in UML use cases) to describe the user interface and interaction with the user.  Funny thing is the user does not interact at all with these words and could care less.  Where are my screens they say.

 

I think one of the ways to industrialize the software development process is to focus more effort on the way a business user interacts with the software.  As software developers we could learn a lot from another industry that has figured this out, which is the film industry.  Before any large amount of money is spent in the actual making of a film, detailed storyboards are developed that layout the complete film before a single frame is shot.  So why dont we use storyboards in our software development process?  This will be the subject of my next post.