Category Archives: iRise

iRise Provides Functional Application Simulations to Accelerate Software Development

Visualizations through iRise give users the ability to create visual, interactive prototypes of new software projects that look and act just like the real thing, before a single line of code is written. This can be a major help in application development. I have written a bit about iRise before (see AppFusions’ Integrations of iRise® Visualization with Atlassian JIRA, Confluence).

Recently, I spoke with Pete Indelicato, Senior Product Manager at iRise, to get a broader overview of their capabilities and an update on their latest moves. Pete primary responsibility is understanding customer needs and defining solutions to meet those needs.  He then works closely with the iRise team of engineers to build out the solutions, as well as marketing for sales enablement.

Pete Indelicato, Sr. Product Manager at iRise

Most recently, Pete has been focused on “platform capabilities” based on APIs that let partners and customers leverage and extend the iRise platform.  He also manages the relationships with their integration partners, like AppFusions.

These extensions, like the Jira and Confluence integrations, allow the iRise platform to better fit into customers’ various processes and ecosystems, and the APIs lets other organizations contribute to and customize the capabilities of the iRise platform. iRise is in the middle of creating a new set of APIs focused on events and analytics.

I asked Pete for a brief overview of their Enterprise offering and how iRise helps their customers.  He began by saying that while communication is key to successful software development, many teams still rely on static documents, pictures and low fidelity click-through prototypes to communicate requirements, interaction design, and more.

For today’s rich, interactive software, these types of communication tools are not enough. The iRise platform allows teams to define and develop software collaboratively while focusing on a high-fidelity iRise simulation as the key communication asset.

These simulations can be constructed in a few minutes by non-technical business analysts or user experience professionals, without writing a single line of code.  You simply have to drag and drop application components to build a simulation. Then you add functionality by drawing lines indicating the course of user interactivity and data flow. In the screenshot, you can see a sample iRise studio screen on a tablet and a smart.

The simulations can then be used to communicate with business and technical stakeholders to make sure the organization is building the right thing.  Then, using other platform capabilities (such as RM integrations and code generation), the latter stages of the software definition and development can benefit from the ultra-realistic iRise simulation.

Pete went over several use cases. First, requirements solicitation can be made more effective. It can be difficult to engage business people who provide requirements when you are limited to offering them a text summary of the design with some static screen shots or a low-fi prototype. With iRise, the designer can show their team how the application looks and, more importantly, works to gather much more effective feedback and reduce the number of iterations and rework.

This same principle operates for interaction designs. Interaction designers can experiment with multiple approaches to solving the same problem while gathering useful feedback from potential users without having to build the software.

Then downstream, communication between designers and implementors is facilitated through the use of simulations of the design that look and act like the designer’s vision. Meanwhile, many related tasks such as documentation and training development, and even selling, can get a critical jump start while the application is still being built based on the iRise simulations.

Pete said that the iRise simulations are the most realistic simulations you can create without writing code and that is one of the reasons they call them “simulations”, not “prototypes”. They not only look accurate (visual fidelity), but act accurate: the user interactions and the data/logic in the simulation are also high-fidelity.  This latter capability is particularly important for efficient software development.

In most cases, the simulations that their customers create are indistinguishable from the production product, developed through code, that comes out months later.

When you think about the level of engagement, quality of communication, and all the parallel activities that iRise simulations bring to the table, the advantage integrations and extensions into a variety of ecosystems becomes clear.

I next asked Pete about their application integration strategies.

He said that very few software engineering / development organizations have identical ecosystems (tools, processes, habits, etc.).  iRise could spend many many thousands of dollars trying to make a complex “one size fits all” product, but instead they are choosing to open their product to integration.  This strategy not only facilitates more efficient internal development of their iRise Connect products, but it allows customers like AT&T and partners like AppFusions to build additional extensions and integrations that help iRise fit in other ecosystems.

iRise Catalog in Confluence. Select Simulation to embed and collaborate around.

The simulations are built on web technologies (HTML, CSS3, etc.). That makes them easily embeddable into other web-based platforms like Confluence and JIRA.  Putting iRise simulations in context of the collaborative environments and other development assets (e.g. story cards) makes that blend of information an ultra-effective communication asset.  Then, when team members not familiar with iRise simulations start to see them embedded in streams and story cards, they will start asking “Where can I get one of those?!”

Pete offered specific use cases for the Confluence and JIRA integrations that AppFusions created. Developers often use the Confluence wiki to create requirements documents. You can embed iRise simulations right in the Confluence-based requirements documents (videolisting). For the JIRA integration,  the issue tracking tool, is often used for more granular requirements or specific issues. (video | listing.)

OCT 8 – 10, 2012 in Las Vegas, NV

Again, iRise simulations can make the communication and handling of these development related issues much more efficient and effective.

Visualize 2012 is this year’s version of iRise’s annual conference where they gather practitioners, customers, and thought leaders for three days of workshops, presentations and socializing.  The 2012 session will occur in Las Vegas, October 8-10.  Speakers include Graeme Hackland, the Lotus F1 Team’s IT/IS Director responsible for all the Team’s Information Systems and many members of the iRise team, including CEO, Emmet Keeffe. They will also be doing workshops on their iConnect capability covering all the ways to use their APIs.

Live preview of linked iRise Simulation in JIRA.

Pete said they are very excited about the potential of their APIs because every day, it seems, someone has a new, inventive idea about a new integration, report, extension, etc.  Of course, they build the APIs with specific use cases in mind, but without fail someone outside of iRise thinks of a way of using iRise APIs in ways they never thought of.  He added that it is a good day every time that happens!

Pete is thankful that innovative companies like AppFusions and SquareOne Solutions are willing to spend some time exploring the possibilities with them. As iRise moves forward it is continuing to expand the number and type of API calls to support further integrations. They are also making significant infrastructure changes to support their more rapid product development.

Where AppFusions Fits – Connecting the Enterprise

Before we describe the place of AppFusions in the new world of Enterprise 2.0, it is useful to go back to look at the Enterprise 1.0 world which is still current for many.

Enterprise 1.0 – “A Single System For All”

In the Enterprise 1.0 world, large ERP systems claiming to be  a “single system for all” integrated many (if not all) departments and functions across a company into a single computer system.  They attempted to serve all the different department needs, running the business, successfully in some places, and not so successfully in others. These systems bridged the needs of products, customers, employees, and suppliers. (Below image from this excellent slideshare by Samuel Driessen.)

Credits: Samuel Driessen

For many years, this cross-functional single-uber-system was thought to be the ultimate glue to solve all problems: the silver bullet solution to propel corporations fast forward in their business success.

However, despite best intentions, these lofty goals were hard ones to meet in a single system, given many mixed audiences and purposes between departments.

  • Cross-functionally, departments wanted to control (customize) their workflow.
  • While ERP systems were configurable out of the box – to a point – in most cases, they required costly customization SLAs to develop or configure the workflow exactly how a department wanted it.
  • Data integrations to other systems were extremely expensive ($50K – $200K+), given the reliance on niche technical knowledge in closed systems.
  • All integrations were like “black magic”, requiring ongoing support and vendor reliance without a natural support path.
  • Integrations where time-consuming and costs could be as much five times the software fees.
  • Over time, specialty purpose-driven or “rogue” systems crept into organizations (large or small), as department heads rebelled against the rigid IT uber-system, and shopped for their own systems to meet their department needs.

For the companies that succeeded in their ERP deployments, they paid dearly in implementation costs, yet also they got bigger and faster with these large system infrastructures. For a while, they enjoyed a competitive edge in their locked-down systems.

Credits: Bertrand Duperrin

In such organizations [2], the general top-down management attitude was:

  • this is how it will be,
  • we do not really want to hear your opinion, and,
  • no, you cannot change the process or system (without an enormous amount of additional churn, cost, pain – to which we have no more money to expend).

Employees were forced to adopt the new inflexible systems, a change that often felt like steps back even from their slower, yet functional desktop processes.

Compounded with normal human resistance to change, the new systems were not always warmly received. People had to conform to rigid systems, rather than having flexible systems built around how people worked best.

The enormous level of cross-functional process coordination upfront, as well as the long term support for these systems, was often more crippling than helping. The systems had the potential to control corporate data in a better/faster way than previous manual ways, but it held employees hostage in so many other ways, and caused new problems organizationally.

Politics and internal fights evolved to ever high levels as employees felt duped when the new systems didn’t really do everything that they thought it would, and no customizations were allowed. If a department absolutely required customizations, they’d have to take the heavy cost hit in their departmental budget (not ITs), let alone the time-hit to implement (e.g., another 6 months often, assuming it got done before some other organizational crisis hit).

Companies would endure the growth of excessive politics, mistrust, and infighting causing systematic morale issues and lower productivity. Employee dissatisfaction grew at a higher than normal rate, as well as distrust for management who forced the new monster system on them in the first place (even if it was justified at the time given where technology was at).

In short – it was a vicious and often ugly cycle, especially for large corporations enduring these growing pains.

Outside the Enterprise 1.0 World, the Beginnings of Enterprise 2.0 Technology Moved Forward

Meanwhile, the open source movement had gained “officialness” in 1998 thanks to Netscape (Mozilla), and during the 2000s, the open source trend and collaborative engineering mindset grew more popular with the growth of Linux, further proving the value of both iterative agile engineering, open APIs, rapid development methodologies, and at the communications level – transparent collaboration.

Concurrently, the Internet was taking off well beyond the Silicon Valley, thanks to Yahoo! (1995), Google (1998) going big/global (as well as Microsoft with Internet Explorer). For the Enterprise, early pioneers Jive Software, SocialText, and Atlassian Software were founded in 2001 and 2002, respectively – three corps that would become pioneers in the Enterprise collaboration tools space in the years to come.

Atlassian also would become a leader in many of the open source stirred trends, namely agile development, ALM, engineering tools, and issue tracking, while boldly treading on common industries lead by big heavyweights like IBM, HP, and Microsoft, among others.

Overall – the timing of these new Enterprise collaboration businesses couldn’t have been better, overlapping with early social sites like MySpace (2003), Delicious (2003), Facebook (2004), Digg (2005), Twitter (2006), FriendFeed (2007), and a strong new-way-to-business Millenials culture pushing into industry with all their might.

The collective force was a perfect storm, landing down on a smug and controlling decades old proprietary industry and decades old command-and-control management styles.

By late 2009, open collaboration and social networking was no longer an idle idea.

It was a fast moving trend and way of the future, that had proven the beginnings of enormous business value for getting things done faster in the Enterprise. Concrete data began to emerge on the quantified value of these new approaches (see The Business Value of Application Connectors).

However, to be successful in the new world, people-centered Enterprise 2.0 apps need to connect with the old world transactional-centered Enterprise 1.0 systems. They needed to connect to each other to avoid establishing even more silos within organizations.

While AppFusions does not really believe in the legacy gigantic one-size-fits-all system ideal, at the same time we know that in most cases, these systems are largely not going away.

The new social systems of engagement still need to connect to the old world transaction systems to get work done.

AppFusions Bridges the Gap with Enterprise 2.0 Content Management Integration Connectors

We believe that business information and process management should be handled by a collection of systems that make up a whole. To make this happen, connectivity is the key driver. It is the glue that makes real work happen. It brings the benefits of social systems to work processes.

Modular system architectures in the Enterprise – from the same vendor or many vendors – provide greater flexibility, while also allowing organizations to pick and choose the best-of-breed systems for their purposes.

There are reasons for purpose-built systems, and a collection of many we feel is stronger than a single rigid system, especially if you can connect the strengths (data and workflows) of the different systems with common use case connectors vs. getting on an endless customization path.

Our integration connectors (current and future) bring together workflows, data files, and information between Enterprise systems for your collective purpose-built Enterprise 2.0 corporate solution of many systems. They allow companies to quickly and cost-effectuvely create the needed connectivity without going through the old-world pain of massive, costly, and time consuming integration efforts.

These connectors provide the means to close the gap between old and new, enabling the promise and opportunity within the capabilities of the new people-centered, social systems.

This blog will become the vehicle to tell this story and provide use cases demonstrating the essential nature of connectors.

Post by Ellen Feaheny, CEO of AppFusions