Posts

hand drawing a rocket ship zooming across space

What is Rapid Application Development, and Is It Right for My Business?

Rapid Application Development (RAD) is an approach to designing software applications where a prototype of the application is developed quickly and then refined through several iterations. It is often contrasted with the waterfall method of software development, where an application is developed in discrete stages: Requirements specification, then design and implementation, and finally testing.

What this simple definition doesn’t make clear is the explosion in demand for Rapid Application Development occurring across a number of industries. Between the relentless drive for more innovative products, the rise of mobile technologies, and rapidly changing business requirements, there is immense pressure put on application developers. Traditional methods of development too often yield products that are “too little, too late.”

To meet this demand, more and more application development needs are being outsourced to companies (like Skeleton Key) that use market-leading platforms (like Claris FileMaker) to quickly build and deploy custom applications for customers. But how does one go about determining whether a Rapid Application Development approach makes sense from a business perspective?

Understanding RAD vs. Waterfall: Keeping an Innovative Edge as Requirements Change

At first, Rapid Application Development might simply seem like a promise to create applications more quickly. Really, it is an entirely different approach to understanding and refining application requirements during the process of development.

To see this, it helps to contrast Rapid Application Development with the traditional waterfall method of development. In a waterfall approach, there are discrete stages of software development: Specifying the requirements, designing the application, implementing the application, testing and ongoing maintenance.

waterfall method of software development

This might seem like a logical workflow, and it is for many types of engineering problems. If you want to build a bridge, for example, the waterfall model makes sense. One starts by specifying the requirements that the bridge needs to meet, and then goes on to designing and building that specific bridge. The final bridge is tested for structural soundness and safety and, if it passes, can then be used.

In the bridge example, the waterfall method works because:

  • The uses to which the bridge are to be put are well defined and unlikely to change
  • The requirements for the bridge itself are also unlikely to change
  • While there might be unforeseen problems or issues, accommodating them will not force one to deviate too much from the original design
  • The bridge itself will not change the nature of the problem being solved (outside of solving it)

The assumptions don’t always hold when it comes to developing new applications. User needs and business requirements are constantly in flux, and application requirements may not be all that well defined (or understood) in the first place. Unforeseen problems, issues or opportunities can mean dramatic rethinking of a given application’s architecture and approach. Furthermore, the software itself can change the nature of the challenges and opportunities that are presented along the way, meaning that even great foresight into business requirements may prove incomplete at the project evolves. The waterfall approach is often too slow to address this kind of problem space.

Rapid Application Development is different. Instead of meticulously documenting requirements and design, the first goal is to develop a working prototype or “minimally viable product” as quickly as possible. The prototype might not meet all possible requirements, and it might even be deficient in some ways, but the advantage of having the prototype is that it allows stakeholders to better refine their requirements and further shape the development of the prototype based on something significantly more tangible than a blueprint or plan.

Rapid-Application-Development-RAD1

So, while Rapid Application Development might not make sense for a bridge—it’s much harder to “just throw up” a prototype of a bridge and make several rounds of refinements—it is much better suited to modern business challenges where software is involved.

What kinds of business challenges? There are several situations that reveal why RAD is superior for building software.

The Business Case for Custom Applications Built with Rapid Application Development

Let’s look at some of the market forces driving the need for Rapid Application Development:

Exploding demand for mobile-compatible apps. Smartphone use has just about doubled over the past five years, and mobile apps now consume 65% of our digital media time. While much of the growth of the market recently has been due to “on demand” apps that promise to make every service more like Uber, there has also been a slow, steady increase in the number of custom applications that businesses use on tablets and phones for work functions. Thus, modern business applications need to be both cross-platform and mobile-compatible.

Application requirements are often nebulous, and changing. In an environment where growth and innovation are ever-present, it’s not uncommon to have the spark of an idea for an application…but not have a clear vision for the application requirements. Sometimes stakeholders need to see what’s possible before they refine those requirements.

Existing technologies are rigid and over-designed. There are thousands of pieces of enterprise software and SaaS solutions out there. One study, by cloud identity company Okta, found that 10% of businesses have more than 200 apps in their enterprise technology systems. Many of these are incredibly rigid and require specialized expertise in each layer of the development stack. On the other hand, many customers end up never using many of the features these solutions offer, and so are paying for wasted features. This is driving more and more organizations to develop their own custom business applications.

From a market perspective, this creates a perfect storm: High demand for custom apps that can function across technology platforms and be easily refined and modified as requirements change, a dissatisfaction with traditional enterprise apps, and an overarching need to get to market quickly.

(For some examples of the kind of custom applications we’re discussing, see our case studies for a manufacturing company, a government agency, a non-profit and a creative team.)

What Are Some of the Advantages of Rapid Application Development (RAD)?

Even if the market need for custom software is apparent, it might not be clear why a business should look to hire a vendor that practices Rapid Application Development using the FileMaker platform. Here are four advantages this approach has for organizations:

  • Enhanced flexibility and adaptability. Developers can make adjustments quickly “on-the-fly” during the development process.
  • Faster delivery time. Small issues that hold up deployment on a traditional development model can be solved at later iterations, giving organizations a functional application more quickly.
  • Code reuse. Functional units of code tend to be used and reused, which leads to less manual coding, fewer errors and shorter testing times.
  • Fewer surprises. By collaborating throughout the development cycle, developers and stakeholders both have a better idea of what to expect. If there are major problems or misunderstandings, the pivot can come sooner.

FileMaker itself is a great platform for Rapid Application Development. In fact, in 2016, software review site G2 Crowd identified FileMaker as a market “Leader” in Rapid Application Development because of its high user satisfaction and ongoing popularity.

If you’re wanting to learn more about Rapid Application Development, or about how FileMaker is helping organizations get their custom business applications up and running faster, contact us for a free consultation.