 Saturday, February 04, 2006
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.
Saturday, January 28, 2006
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.
Saturday, January 21, 2006
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
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
Thursday, January 12, 2006
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.
Wednesday, January 11, 2006
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.
Friday, January 06, 2006
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.
Thursday, January 05, 2006
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.
Sunday, January 01, 2006
Computers and software has become so pervasive in our daily lives it is hard to imagine doing anything without it. In fact, virtually everything we touch daily is powered by a chip of some sort and we as humans interact with the software running on it. Whether it is our cell phone, iPod, digital camera, television, video, car or the software we use at work and play, software is everywhere. With the price of computers continually dropping and the power continuously increasing, coupled with exponential growth in internet connectivity, there is simply going to be more software in 2006 and for years to come.
However, a fundamental problem still exists in the world of software. The process of creating software is still a labor intensive, error prone process that is fraught with complexity, bugs, schedule/cost overruns and unhappy users. To non-software professionals who are the masses that make up the software user community, software seems to be doing ok - maybe. I can listen to my iPod, while getting email on my computer and seeing text messages come in on my cell phone. However, what the masses dont see is the incredible effort required to design, construct, test and release any type of commercial software that has minimal bugs and meets your requirements.
As a software developer, the process we use to design and construct software is still trial and error at best. It may come as a surprise to non-software professionals that there isnt a predictable and repeatable process for developing quality software on time and on budget. While there are hundreds of books and thousands of articles on how to design and construct software, they are all different, with no tried and true process. Of course there are commonalities, but as the saying goes for every user requirement, there are a thousand designs and for each design there are a thousand ways to implement it. The variability in how we develop software is the curse of our industry.
Over the last 15 years as a software professional, I have worked on many software projects and products, some small, some very large and a lot in-between. I have also worked with hundreds of people on these projects. As I reflect on those projects, I realize that the ones that succeeded were based mostly on the highly skilled and competent people working on these projects.
Perhaps another surprise is that a lot of these people did not have Computer Science degrees, but rather came from all walks of life, however, all of these people had one thing in common they knew intuitively how to design and construct software. While some of this can be attributed to experience, most of it was an innate ability to read words as user requirements and translate those words into a working software program that somehow met what the user (community) wanted and was done on time and budget.
So what does this mean? It means that the design and construction of software, particularly business software, is still an unindustrialized process. What do I mean by unindustrialized process? I mean that we have progressed very little in the way of automation. We still hand-craft software just like cars were handcrafted before the concept of producing parts that were then assembled. That was almost 100 years ago!
It still amazes me that we have this incredible technology called software, yet our process of creating this software is quite archaic. On the industrialization scale, compared to other industrialized disciplines like manufacturing, building construction, electronics, etc., we are decades behind. What will drive industrialization in the software industry? This will be the topic of my next post in this series.
© Copyright 2008 Mitch Barnett - Software Industrialization is the computerization of software design and function.
newtelligence dasBlog 1.9.6264.0 Theme design by Bryan Bell  | Page rendered at Saturday, October 11, 2008 7:33:50 AM (Pacific Standard Time, UTC-08:00)
|
|