How Rapid Application Development is Changing Everything
Saturday, September 24, 2016
|
Richard Harris |
I admit it, every time I hear the word RAD I go back to the 80's when BMX freestyle was at it's peak (I still own my beloved GT Performer)! But the RAD we are talking about here is "Rapid Application Development" (RAD), that used to be something reserved for making quick apps with minimal code input, little functionally, and that you did not intend on maintaining for very long.
But in recent years RAD has evolved into a very viable option for just about any type of app project. Vijay Pullur, CEO of WaveMaker talked to us about the changes RAD has gone through, the advantages of RAD in the cloud, low-code options, what application projects are best suited for a RAD build, and more.
ADM: What do you see are challenges faced by IT leaders responsible for application development and Delivery?
Pullur: There are two main reasons why IT leaders need new approaches to application development and delivery.
Gartner refers to two approaches, which it identifies as Bimodal IT;
- Innovate (Innovate or Die has become a mantra in virtually every enterprise)
- Renovate (renew existing applications; for a variety of reasons discussed later).
Each of these two approaches has a different set of challenges.
The key Innovation Challenges are -
a. Shortage of technical people: Finding the right team (skilled in full-stack development) on time. This is a challenge, given that there are plenty of applications to build (both web and mobile; I’ll simply refer to them as apps from here on).
b. Project Delays: May be caused by delays in setting up the team or resources, most Innovation projects run longer and that is harmful, as one rarely knows which innovations (software powers most) would work.
c. Excessive cost/budget: One should always factor in scope-creep; where requirements keep moving as the project progresses. Giving the importance of maintaining an app, this component is essential when calculating the Total Cost of Ownership (TCO) of the Application delivery project.
The key Renovation Challenges are -
a. Integration with existing applications: Loose coupling is the trend of the day and nicely facilitated by HTTP-based protocols such as REST (compared to SOAP-based integration). Many of the existing applications in the company may not have defined REST APIs (or custom extensions to standard products may mean some API effort). Most common integrations are with CRM, SCM and other Systems of Record applications.
b. Design of Good APIs: Where new APIs are being built, scalability and versioning are big concerns. When APIs are augmented, it should be possible to rebuild the app to this new version without a significant effort.
ADM: Can you share some practical strategies for enterprises to innovate faster with lower costs and risks while meeting their business goals?
Pullur: Here are a few strategies enterprises can use:
a. Enlarge the number of people who could innovate (and can translate innovation into applications). This can be achieved only through lowering the skills needed for application development and delivery. Unfortunately, modern apps need multiple skills (from front-end to back-end), and some of them are complex and fast-changing (for example, media queries, responsive design, and grid layout).
b. Bring pre-approved platforms and tools needed to facilitate faster delivery of Apps. BPM systems once served well, when the UI of Apps was not a significant factor (consumerization of IT has changed app user expectations). Modern Apps must follow many design guidelines, practices and standards (for example, material design). Unfortunately, BPM systems followed a No-code approach, rather than a Low-code approach, making them unsuitable for today’s needs.
c. Define and create corporate standards that enable true reuse. The cost of adherence to corporate design standards (be it fonts, colors or themes) needs to be brought down by choosing platforms that enable such practices. The work done by highly capable engineers should be reusable across Apps to reduce cost, time or effort and to provide consistency across projects. One place we find huge software waste due to lack of reuse is on the front-end (why should everyone write similar code from scratch for each project?).
ADM: There are some clear advantages of moving apps and data to the cloud. What would you tell business leaders to help them with cloud migration?
Pullur: The primary advantages of moving to the cloud, as I see it, are:
a. Taking advantage of the reduced cost of infrastructure setup and upkeep. With IaaS (Infrastructure as a Service) becoming commonplace, thanks to Amazon AWS and Microsoft Azure, the cost of hardware is next to nothing. This move also converts CAPEX to OPEX, thus freeing up the limited budgets of today. That’s why many companies are even resorting to lift-and-shift migration strategies to hurriedly move to the cloud.
b. “Real” big data is now possible because cloud-based storage is extremely cheap. Storing everything now to see patterns later is a strategy common in many companies.
c. The cloud is freeing up budgets for software innovation. Now that hardware resources are made cost-effective through IaaS, a good PaaS (Platform as a Service) layer makes it even cheaper to build and deploy Apps.
Some of these advantages are critical in enterprises looking for inexpensive experimentation. When PaaS or the App provides APIs for programmatic retrieval of data, the vendor or software lock-in is zero. This freedom to move out, if and when needed, is turning out to be an important decision factor.
ADM: How has low-code / RAD evolved to solve today’s application delivery challenges? What productivity gains can be expected?
Pullur: RAD platforms have evolved from “Quick and Dirty” Apps (which were more like prototypes) to “Nice and Final” Apps (ones offering a great user experience). As we see a rampant spread of “consumerization of IT” (i.e., corporate Apps that match consumer Apps), RAD is seeing a resurgence. Today’s RAD platforms are nothing like their earlier cousins, although the goals of bringing rapidity remains.
Some RAD platforms combine a 'developer cloud' to reduce cycle times further (test-as-you-build) and increase productivity. This also makes it simpler to move an App from the developer environment to staging or production (say through use of containerization technology).
The productivity gains are achieved through:
1. App composition (from pre-made components) instead of App programming (writing from line 1).
2. App testing while development through single click preview on a simulated target platform (assuming the PaaS provides an easy way to verify how convenient the interface is under different form factors).
3. Reuse of software components that go into the App.
4. Ability to quickly move an App from development to production.
5. Team collaboration that speeds up use of each other’s work, without stepping on the toes of the others, and while safe keeping of the source and other artifacts of the project under version control.
ADM: What types of Apps are best suited for RAD delivery?
Pullur: RAD platforms should not be used for developing gaming or other highly interactive Apps with very little data. By that rule, one can easily rule out Angry birds and Uber-like Apps.
RAD is most suitable when the Apps are data-driven (most often populated from a database system). Pagination of data or memory management (for example, a mobile App that brings in too much data ahead of use, may waste data traffic, whereas one that brings too little could provide poor interactivity), is very tricky particularly when Apps need to use AJAX. AJAX is a very common form of programming, for both web and mobile Apps, where data is fetched on demand (or Just In Time). Such AJAX applications (also called single-page-application, as data is called into the same page without need for server fetch of a new page) provide a better user experience and are hence preferred.
ADM: How should enterprises think about putting a RAD practice in place? What are the ideal skill levels and team composition?
Pullur: Yes, every enterprise has to think of a RAD strategy, as it helps in two important ways. 1. Faster App delivery and more consistent UIs that match their corporate branding guidelines and design guidelines for the target device (for example, switching off OK and Cancel buttons, when the App was originally designed for a different platform, could mean disaster, not just lower adoption).
The skill level of people on the project depends on the RAD platform of choice, but certainly lower than the skill set needed for development through programming languages. Customization of standard Apps – assuming every App today provides a certain degree of flexibility, a normal business user can do the customization without the help of an IT person – needs the lowest skill level. It’s a continuum (as shown in the picture below), all the way to App programming that needs pro developers, who are skilled in different technologies (HTML, CSS, Javascript, API, Security, Java, DB design, etc.) and many best practices (such as design patterns, UX fundamentals, etc.).
ADM: What are your thoughts on business (citizen) developers collaborating with professional developers for application development? Can RAD platform truly empower citizen developers?
Pullur: Today’s RAD platforms are not designed to be No-code platforms (unlike their BPM cousins) that needed zero understanding of software or IT. They reduce the complexity by removing the need for highly skilled professional developers for non-trivial App development. That makes it inexpensive to deliver an App through a thin IT team (developers to supplement functionality-focused business teams or true citizen developers who have limited background of software technologies).
RAD platforms truly empower citizen developers, who straddle the line between pure business folks (shying away from any software development or deployment tasks) and professional developers who are capable of building the most complex parts of the App. If the RAD platform enables 2-pass development, such as WaveMaker, where the first pass is the work done by professional developers in preparing the components that go into composing Apps by pass #2 development, then citizen developers can be participants of such development with confidence. They can also be retrained in the use of RAD from whatever older technologies they might have been familiar with.
ADM: Enterprises are looking to mobilize their workforces. Can you share some best practices to deliver these apps in a cost-effective manner?
Pullur: Enterprise mobility has significantly enhanced the need for new Apps. Such Apps need to work on (be installed on) divergent set of devices (rapidly changing form factors and interaction capabilities). Many enterprise Apps need to work on multiple devices including PCs and laptops, and hence the need for a common back-end that can serve multiple front-end devices (loosely coupled through an API).
The best practice for a post-web-era application is to publish an API that lets south-bound (back-end service) and north-bound (end user front-end) development (app evolution, that is) happen independently.
ADM: For enterprises used to building things from scratch, is RAD a disruptive application development practice?
Pullur: Most progressive enterprises are looking at the benefits that RAD brings. The challenges of lower budgets and the people shortage are universal, and the gains of adopting RAD are great and are long-term, hence enterprises are looking at adopting RAD. Participation from business users during early App development is crucial, as no longer can businesses wait for the long, drawn-out RFP process (often 15-24 months). Neither can businesses be comfortable with the complexities of a fast-changing technology landscape. RAD platforms provide a middle path for them.
Similar thoughts existed when Agile software practices were introduced. However, Agile is now mainstream and part of every enterprise’s thinking (iterate on features and release often).
ADM: How can a Low-Code platform fit into Gartner's Bimodal IT practice?
Pullur: Gartner Bimodal IT has to be looked at along with the theory of Pace Layered Architecture. The following picture captures them together neatly.
Mode 1 refers to legacy modernization, and Mode 2 refers to expenditures on new systems or Innovation. Companies look at their expenditure plans this way and low-code platforms need to help enterprises achieve this vision. Many BPM companies that provided platforms for the mid-tier (Systems of Differentiation) are now engaged in building/partnering with RAD or low-code platform providers.
A more detailed understanding of Bimodal IT and prevalent models in HR is available at https://www.linkedin.com/pulse/understanding-bimodal-how-applies-hr-technology-john-macy-fahrilife-
ADM: Why should a low-code platform be a CIO’s best scheme for ushering in digital innovation in the enterprise?
Pullur: I believe CIOs must choose a low-code platform for ushering in digital innovation in their companies. No one can predict where the innovation can come from or which company can succeed in the market. Hence, before making big plans on App development, CIOs today are showing preference for low-code platforms as a means to get Apps built rapidly. (Fail Fast is a good startup mantra!)
A true low-code platform removes the traditional delays of IT and the provisioning of resources or software, empowering businesses to innovate faster and on their own. Apps help nimble startups level the playing field and compete with behemoths – a critical advantage, especially in a dynamic or volatile market.
ADM: What special considerations for mobile app development set it apart from traditional enterprise app development?
Pullur: The main consideration for mobile app development would be the choice in the type of App to build, and those fall into three classes: Responsive, Native and Hybrid.
- The Responsive App is one that needs to work on the mobile browser in addition to a typical browser on a PC (desktop or laptop). The access to the App is by typing in a URL, and the App should support smaller form factors, although it may not support mobile-specific interactions (such as gestures) or mobile device capabilities (such as cameras), as the app operates in a typical browser environment. The Responsive App should resize and reposition its components based on the available screen real estate.
- Native Apps are faster, installed on the phone (and they might access a backend server) and provide complete access to mobile device capabilities. However, Native Apps are harder to program and needed to be redone to support a newer device or OS.
- Hybrid Apps provide the middle path, in being easier to develop and maintain (due to the use of web technologies such as HTML/CSS/JS) as well as to maintain while providing the ability to access device capabilities packaged and installed on the phone. Many platforms that help enterprises develop mobile apps use Apache Cordova (the software behind the popular PhoneGap service from Adobe).
At WaveMaker he is responsible for corporate strategy, executive hiring and sales. He has deep expertise in scaling startups and growing them into large businesses.
Previously he spent eight years in technical leadership and software development roles at Wipro, India's software giant (NYSE:WIT).
Read more: http://www.wavemaker.com/
Become a subscriber of App Developer Magazine for just $5.99 a month and take advantage of all these perks.
MEMBERS GET ACCESS TO
- - Exclusive content from leaders in the industry
- - Q&A articles from industry leaders
- - Tips and tricks from the most successful developers weekly
- - Monthly issues, including all 90+ back-issues since 2012
- - Event discounts and early-bird signups
- - Gain insight from top achievers in the app store
- - Learn what tools to use, what SDK's to use, and more
Subscribe here
