I meet with CIOs, application development groups, business analysts and architects all the time.  Our initial conversation always goes the same way; I explain what visualization is and why it’s important.  Within 60 seconds everyone, and I do mean everyone, GETS it.  You can SEE the light bulb go on.  Then….I wait for the inevitable question; “If the visualization is an exact replica of the application, why doesn’t iRise simply generate the code?”   Without fail, that question is asked in every single meeting.

Actually, it’s a really good question (it must be with so many people asking it).  But there are really good answers as to why iRise doesn’t generate code.  Let me try to articulate them here.

1. What code do you generate?  That’s a tricky one, since everyone’s architecture and standards are so different.  Do you generate Java/XML?  .NET?  SOA?  Which flavors?   If you had to worry about getting the code generation right, you’d quickly run out of resources to figure out all the combinations, test them and support the result.  This sounds a lot like the old CASE tools strategy in the 1980’s and 1990’s.  See how well THAT worked out.
2. iRise is specifically designed to be easy to use for business analysts, not developers.  The problem that iRise solves is getting business needs documented visually.   This is a business-facing challenge, not a developer productivity challenge.  If you started to worry about code generation in iRise, the product would become too hard to use and understand for business-facing analysts and usability professionals. 
3. Our primary emphasis is on rapid, high fidelity visualization.  To put any amount of emphasis on code generation will slow down the ability to visualize the right business needs quickly and rapidly iterate to the right result.  You don’t want to be distracted with figuring out ‘what code should I generate’ during this part of the process.  The people creating visualizations are the wrong people to be worried about code generation – that’s the job of architects, software designers and developers. 
4. And of course, the flip answer is this: “There’s no button on the side of the flight simulator for the Boeing 787 that generates the airplane!”   There MUST be a reason that other industries invest hundreds of millions in simulation technology without having the capability to simply press a button and build the thing.   You visualize things before you build them to produce better, safer products more quickly, with lower cost and risk.  The same is true with software and iRise visualizations.

It’s important to note that even though iRise doesn’t generate code, most of our customers report a 25% – 50% reduction in application development time due to the fact that proper visualizations virtually eliminate rework and allow downstream organizations like QA, training, documentation and marketing to get a head start on their work.