Most of us who have delivered more than one app know that the majority of these turn into applications. That transition from ‘app’ to ‘application’ brings new challenges from the initial prototype and deliver process. Adding all of those extra features requires us to slow down our velocity a bit to test all of the new inter-connectivity. In this post I want to share with you my perspectives on what it means to transition an ‘app’ into an ‘application’.
First, let me define the difference between what an app is versus an application. For me, a business app typically has a limited amount of features that execute on some core functionality whereas a business application has to consider all of the exceptions to the business process, thus becoming feature-rich.
Often times the idea for a new app comes about because the business realizes that they need to capture some data. They might need it to help them make decisions but more often they realize that the captured data needs to route somewhere due to business processes. Using a tool like Mendix, we realize that we can capture and move data around with some basic workflow parameters in a very quick turnabout. When you see the performance claims of turning around an app in days or weeks as opposed to months or years, this is the kind of functionality you are talking about. Get it built, make it good enough, and get it out there to be used. Benefits are immediately realized and everyone wins in terms of time and money saved and processes being optimized.
At some point in your app’s life-cycle, the business is going to suddenly “realize” all of the exceptions to the process that the app is supposed to help manage. People that get data routed to them might be sick or on vacation, they might bring their own device instead of using a PC or Mac, or certain cost accounts always need to route to a specific person or department. Whatever it is, that core feature to capture and move data in your app suddenly isn’t sufficient for all of the exceptions to a business process.
There isn’t a set number of features that changes an ‘app’ into an ‘application’ but people tend to think of apps as lightweight and applications as fully-featured. These features that address the work-arounds, exceptions, and “nice-to-have’s” are really the tipping point that transitions an app into an application. The challenges now shift from how quickly you can enhance and respond to the changing needs of the business to considering how the new features might impact the already-in-production app and its user base.
You see, RAD (Rapid Application Development) coupled with SCRUM is excellent at taking an idea, prototyping it, and deploying it as an app. But the iterative process is also inherently buggy. Your team isn’t going to spend as much time regression testing in order to get the app “good enough” and out the door. When you start to transition a production app into an application, you have to start considering all of the regression effects of a design feature and test accordingly. This grinds the speed of innovation drastically.
The way to deal with this is to be prepared and communicate early and often. Set the expectations that during the prototyping phase bugs are going to likely be rampant, but once you get it working and out into production and these “new feature needs” are uncovered, the process is not going to run as quickly as it did during the build phase. Since most users are accustomed to Waterfall, where they sit in some requirements gathering sessions and go away until something is delivered only to be disappointed, you have to educate them how this process differs from that one. Yes, there will potentially be more bugs in the build phase because it’s all about the pace of change, but they’ll be getting what they need at a much faster rate and be on-target.
Your lightweight apps have a good chance of becoming fully-featured applications. Be aware that each feature multiplies the potential bugs because of how the features inter-connect. I don’t have the sure-fire way that you’ll avoid bugs, but I share this to help coach you to communicate early and often with your business owners the differences between how they were used to interacting with IT and how this new RAD process will meet their needs faster with the caveat that it might be a bit more buggy along the way. If your users know what they want and bugs are not tolerated well, then RAD probably isn’t the right approach. But no matter what approach you take, know that your app is likely to become an application at some point so consider that during your design and prepare your business owners with constant communication about this paradigm shift.