In-Depth

Q&A with Emmet B. Keeffe III, CEO and co-founder, iRise

Q: What were you trying to do at iRise when you started out?

A: Well, we were trying to figure out how business people and IT people communicate, and what we could do to improve that communication. And we found that the most painful area of communication was requirements. As we looked closely at [the problem], we figured out that text documents, spreadsheets, Visio diagrams and PowerPoint screenshots are the way business people and IT communicate, and it’s just a very tough way to communicate about requirements. So we wanted to come out with a new technology that would allow [these groups] to communicate in a different way. We came up with the concept of visually simulating requirements so that business people can look at the simulations and make sure that the requirements are correct. This way, when you ultimately pass the simulation over to developers, they have a much better idea about what the business wants and can build a system that’s going to meet their needs.

Q: We know simulation from old video games, and from climate studies and integrated circuit creation. Why has it not come heretofore to this application?

A: That’s a good question. I think one answer is that software is a relatively young industry. It’s only been around for 20 or 30 years, and Web-based software, specifically, has only been around for about 10 years. [In] more mature industries, like the aircraft industry or the semiconductor industry, simulation ultimately became a standard practice. We think software is just to the point where it’s time [for this to happen] from an evolution standpoint. Another thing we’ve thought about is that most of the innovation so far has been in the [following] areas: How do you deploy software? How do you secure it? How do you integrate it, build software and buy packages off the shelf? A lot of the automation has been focused on IT productivity so far, and we believe that the natural evolutionary step is to focus on automating how business people actually communicate to IT what they want, and that’s what we do.

Q: Now developers sometimes can be a little difficult to work with. But isn’t it true that business people have trouble describing what they need?

A: Absolutely. It’s almost as if you have two different people that speak very different languages. The business people think very, very high level. They think about ideas in sort of a non-technical format, while developers tend to think about code, integrations, data models and things like that.

I was presenting our solution to a very hardcore developer, and at the end I asked him, “How would you explain this technology to the darkest developer you can possibly imagine?” And he said, “I would explain to the developer that with iRise you’re going to have to talk less to business people.” Which is what developers would prefer to do — just write the code. And if business people can give them a simulation, there’s just far less communication needed.

Q: You hook your tools into, for example, other tools from Rational, Borland or BEA. How is the integration or output similar or different going through those three cases?

A: We think about iRise as a business analyst productivity platform, and we wanted to integrate that business analyst platform to developer productivity platforms. The first one that we did was to Rational RequisitePro. And the way that works is that if you have stored your text requirements and use cases in Rational, you can view them up into iRise, create the simulation, and then associate the simulation directly to the text or the use case. Now you have traceability all the way up into the actual simulation. The Rational release is all about traceability for future impact analysis.

The way that the Control Center integration works is that once you’re done simulating the requirements in iRise, and when you open up TogetherStudio, you can see the assets coming from iRise and then associate them to the UML diagram and whatever artifacts you want to within the Together environment. Again, we’ve established traceability between simulation and the design artifacts.

The BEA integration was actually the first of its kind. What we’re doing is that when you’re done simulating with iRise, you push a button and it pre-generates a whole bunch of development assets into the workshop environment so that the developer gets jump-started. The page flow diagram is automatically created, JSP code is automatically generated and text requirements are displayed into Workshop. When the developer opens up Workshop, they sort of have a scaffolding laid out of the application and they can push a button and pop up the corresponding simulation for each requirement. It’s the first of its kind where we’re actually generating some development assets.

Q: We always like to ask what’s new in the product. Usually changes are at the behest of users.

A: That’s right. Version 3.1 is all about making the product orders of magnitude easier to use. The thing about business analysts is that they really only know how to use Word, Excel, PowerPoint and Visio. What we’re trying to do with iRise, is to provide them with a platform where they can create a very high-fidelity simulation that looks and behaves like a real system. With Version 3.1, the business analyst can create an even richer simulation, and the idea there is that they can discover more missing requirements. If you can let your business customer step through a transaction, enter data, see data being displayed and see calculations happening, you’re going to find errors and communication problems up front.

Q: I’m thinking that the advent of standard application servers helps you, and we’re thinking that the next frontier above that server is business process management (BPM). Is that the focus of your product?

A: When business process analysis first came out, it was about sort of laying out your business process and simulating the business process. The feedback we heard from the market is that there just wasn’t enough value there as compared to Visio or some sort of other technique of laying out your process. So a lot of the business process vendors are moving toward business process management, which is all about being able to actually create a runtime application once you’ve completed your business process modeling.

Our view on BPM is that it’s going to be a developer productivity tool and it’s going to shake up the developer tools market as we know it. We also think it could shake up the application life-cycle market as we know it. But we view iRise as solving a different problem. Right now, what business analysts do is that they document requirements using Word and Excel. We’re trying to give them a way to simulate the requirements to make sure that they’re well understood so that once those requirements are handed over to either the developer or the analyst who is going to do the process flow, they’ll have the best possible information. So we view our platform as sort of a step before BPM.

About the Author

Jack Vaughan is former Editor-at-Large at Application Development Trends magazine.