WaveMaker
close
LOW-CODE
PREFABS
SOLUTIONS
EVALUATE

Wired for experience®

WaveMaker

Any enterprise that got its start before the dawn of the internet era comes equipped with a legacy in its systems of records that are several decades old.  These systems have been through multiple patch and upgrade cycles over time, making them inflexible to change. Simply put, these systems may create more problems than they solve.

And yet Gartner predicts that, even by 2023, 90 percent of enterprise applications in use today will still be in use.

These systems of record have proven themselves to be a competitive advantage for the enterprise over the years, and they can’t be wiped off the slate – simply because there’s nothing to replace them. In a recent survey conducted by BT Global Services, 42 percent of enterprise leaders said they would continue using their old systems, and 37 percent said they even planned to upgrade these systems. And, contrary to popular belief, a BMC mainframe survey last year revealed that 91 percent of enterprise leaders expect their workloads on mainframes to grow.

The problem in keeping these systems running is that the Baby Boomer generation is retiring, and the skills needed to maintain them are dwindling. Look at mainframes, for example.  They aren’t part of any graduate curriculum today, and are not of interest to the young technical workforce. The skills needed to develop old applications written in programming languages, such as COBOL, FORTRAN, Assembler and even C, are not readily available, forcing enterprises need to spend considerably to train and onboard skilled staff.

Modernization: The New Imperative

Now let’s examine modernization.  Modernizing software systems has been a cornerstone of the offshore IT services industry. Modernization today is platform-led, very different from the earlier era in which modernization was a services-led initiative powered by selective platform use. There are two main reasons for this:

  1. Three- to five-year roadmaps are dead. Consider this: spending one year, using a dozen developers at a cost of $1 million to build applications is no longer feasible. Modernizing is about quickly changing direction for new opportunities. To achieve this, a healthy interplay between platform and services is critical. Services alone can’t cut it anymore.
  2. Enterprise IT has to do more with less. The recent 2018 Connectivity Benchmark Report from MuleSoft stated that IT decision-makers report an average of 27 percent more projects for 2018 over 2017, while IT budgets, on average, will either increase by less than 10 percent or stay the same.  Something must give.

From Legacy to Neo Legacy

The move from 3GL to 4GL has been making the modernization rounds for a number of years.  Unlike 3GLs (C++, Java etc.), 4GLs allow the developer to focus on an app’s business logic and presentation, and not just on writing lengthy code. Developer productivity was the core promise of 4GLs and platforms, such as FoxPRO, Microsoft Access, and PowerBuilder, enabling rapid application development. The problem is that 4GLs were built for an earlier era.

But 4GLs are proprietary, and inevitably result in in vendor lock-in.  Plus, enterprise software licensing costs for 4GLs are continuously increasing. And, despite their promise, they required a lot of manual coding. What’s more, their scope of use is limited to specific application scenarios, which are determined by app vendors.  Unfortunately, that leaves little scope for customization and exploration.

Unfortunately, many 4GLs were developed before the “digital era” and long before the need to support the web and mobility.  Thus, 4GLs are not suitable for the device, data, and integration requirements of today’s enterprises.

But now, low-code application development platforms have stepped in. Their promise is not only to simplify coding, but to drastically minimize or eliminate the need for massive code bases, and doing so results in faster and future-proof development.

From Traditional Code to Low-Code

Low-code platforms have become one of the tools of the trade for app modernization.

  1. They offer full-stack visual development and application management capabilities. They enable enterprises to quickly build, test and run enterprise-grade mobile and web applications with minimal code. Enterprises can experiment and innovate with less risk of traditional methods.
  2. Applications built using low-code platforms are modular by nature, so the cost of an application change is reduced.
  3. Open standards-based stacks give low-code platforms the openness that 4GLs lacked, and they let enterprises avoid expensive vendor lock-in. Low-code platforms can be used for a range of requirements, from simple automation of paper-based processes to creating new systems from the ground-up.
  4. Applications built using a low-code approach are robust, secure and can be a seamless extension of existing data sources and legacy systems. These platforms also offer pre-built connectors and pre-fabricated components. This makes applications extensible and customizable, and helps leverage the power of API economy.
  5. Built-in DevOps and container management capabilities help low-code platforms deploy applications into, and between, existing infrastructures. This accelerates the code into the customer journey.
  6. Low-code platforms help enterprises better align with the future of software development. Today, the answers to most business problems are in the data owned, not in the software used. Hence, spending a year and a million dollars to build enterprise software cannot be justified. Model-driven, componentized assembly of software is the future and low-code platforms aid such emerging ways, making development efforts future-proof.

Where to Start

 How can you transition to app modernization using low-code development?  Here are my recommendations:

1. Evaluate the technical condition of your systems and bucket them as low or high depending on your perception of these five parameters:

2. Decide whether the code base needs to be touched

If applications do not need to be modified but need to be updated, there are three common approaches: wrapping, packaging and re-platforming.

If the code base needs to be modified, approaches such as refactoring, rewriting and re- architecting should be considered.

Additional Considerations

A packaging approach that replaces legacy software with COTS software is suitable for systems of record but shouldn’t be used for systems of differentiation. This is because all companies have access to apps, such as Salesforce, that erode the opportunity for differentiation. Such systems need to be approached with either rewriting or re- architecting, both of can build competitive advantage.

Systems of differentiation can be approached using a wrapping strategy, which is typically lower cost.  However, the benefits of wrapping are temporary and should be used a stepping stone to a rewriting or re-architecting. All other approaches except wrapping reduce the burden of finding skilled legacy resources.  Why is wrapping singled out?  Because wrapping simply allows new functionality to be developed on top of old systems.  Companies still need active mainframe and COBOL development teams post-wrapping.

Finally, enterprises need to acknowledge the technical challenges faced by IT and developers during modernization projects.  These include:

Modernization is a practice whose time has come. But perhaps the true test of any modernization platform is that it must not come at the cost of an army of specialists, but instead must set the stage for sleeker, more people-efficient IT organizations.

 

Originally published by Vinay Murthy, VP of WaveMaker in EnterpriseTech

 

Practical Steps to Achieve Enterprise Digital Transformation

One of the most talked-about things in the IT industry these days is “Digital Transformation”. For CIO’s and IT decision-makers, this means migration of their existing applications, built on legacy technologies that are so out of date, that they are afraid to tinker with them. While still others feel the need to catch up to modern technology and leverage Cloud deployments for significant cost savings. If nothing else, their internal users and customers demand modern systems.  

The questions that CIO’s and IT leaders get stuck are along the lines: “How do I go about this Digital Transformation?”,  “Where do I start?”, “Which vendor do I pick for this transformation?”, “Which technologies should I bet on?”.  Read on to see some very straightforward ways to achieve your dream Digital-Transformation in your organization.  

Create a Request for Proposal

Start by putting together an RFP that captures the essence of your existing application (say legacy CRM system) and what you envision would be its most modern version (open source technologies, responsive design, deployed in the Cloud, etc.)  In addition, you also need to come up with a rough timeline for the execution of this project (month level accuracy is ok) and a rough budget for the entire transformation project.   Once you have created this RFP, it is time to source several vendors who can help you with this transformation (System Integrators, Platform Vendors, Industry Specialists, to name a few ).  Talk to your colleagues for references and fully leverage your procurement team for sourcing. Your procurement team can help send out this RFP and shortlist vendors based on high-level criteria for meeting your timeline, references, and estimated costs for Discovery and Implementation Phases (more on this shortly)

Evaluation Phase

The best way to pick a vendor (assuming several bidders) would be to put them through a “real test scenario”.  Create a Proof of Concept requirement document (POC) that you would want all vendors to execute in a short period (weeks, not months). Once POC is completed by the vendor, have them come to your office for a detailed discussion around their platform, technology, services, and how they went about building your POC.  By comparing apples to apples, you will have a good sense of the vendor that is right for you.   Based on their performance at this stage and their cost estimates for the next three phases, you would be able to shortlist and select the vendor for your project.  This is also the time to negotiate a contract and deliverables for the next phase.

Discovery Phase

This is the phase, where the selected vendor would bring in their team of Business Analysts, Architects, and Designers and capture all your business and technical requirements.  On your end, you would have a Project Manager to manage various internal stakeholders, schedule meetings, and approve documents captured by the vendor.  This is also the time to come up with improved workflows, discarding any sub-systems that are no longer needed as well as chalking out a long-term plan for maintenance and upgrades.  At the end of this Phase, ask the vendor for the final cost estimation for the Implementation and Maintenance Phases that are coming up next.

Implementation Phase

In this phase, your chosen vendor would work very closely with your IT and Business stakeholders as they gradually roll out the project according to a well-defined plan. This should not in any way disrupt your existing business. But at the same time, your vendor will start training and gradually bring your team on to the new platform.  It is critical that your users get accustomed to the new system, give feedback for improvements, and help vendors with business validations. If all goes well, you should have a new system that was well thought out, executed, tested, and now deployed in the Cloud.  

Maintenance Phase

You should have a vendor agreement in place by the end of the Implementation Phase for at least a couple of years of maintenance.  This phase would include adding new business requirements, workflows, or changes to the user experience based on feedback.  This Phase can be executed on a Time and Material model with the same vendor (or have a contract for say “100 man-days” for maintenance).  Also, as part of your contract with the vendor, ensure that you have all the licensing in place for any technology platform that they may have introduced.  

 

 

As a user, what is the first thing that comes to mind when you hear the words: enterprise software? Perhaps something difficult to use and gray in color? Maybe a dinosaur-like UI that gets in the way of your productivity? But how did this come to be? Let us rewind the clock to a few decades ago to understand how enterprise software was purchased and used.

Enterprise applications were designed to meet the complex, scalable and mission-critical needs of an organization. Purchase decisions were (still are?) made on spreadsheets and it was difficult to quantify the user experience. From the user’s perspective, there was a wide gulf between enterprise and consumer apps - with a different set of expectations from each. It was also a time when software purchase was a one-time activity or riddled multi-year maintenance contracts. Due to the high switching costs, poor user experience was a barrier that was not high enough. Also, organization culture leaned towards a “just get it done” attitude especially when it came to internal tools, resulting in user experiences that weren’t well designed or tested.

The times, they are a-changin'

While the hangover of yesteryear remains, the state of enterprise apps UX is changing rapidly. Consumerization of IT and user interfaces from the consumer world are setting the bar now for enterprise software. With the advent of cloud, social and mobile, the gulf of expectations has narrowed because we are switching between apps related to work and play throughout the day. Enterprise employees are also consumers, and they’ve come to expect consumer-level design in all the tools they use. The millennial workforce expects enterprise apps to be fast, connected, and available on all devices, at all times. Meanwhile, SaaS has lowered the cost of switching and encouraged competition - moving the battleground from the spreadsheet to user experience. Also, the adoption is clearly measurable, hence, the user experience is now more quantifiable than ever. Moreover, enterprise software makers are using design thinking to create the best possible applications. Due to all these reasons, even internal apps, custom applications, and partner apps are expected to be of the highest quality with respect to user experience.

How to create enterprise apps with consumer-grade UX?

Good design also enables enterprises to eliminate inefficiencies and extra costs that are passed on to the end-user in time spent, money lost, and frustration increased. In fact, when an enterprise prioritizes user experience for its internal tools, it becomes a more effective organization; recent studies show that design-driven companies outperformed the S&P average by 228% over the last ten years. So how does an enterprise create enterprise apps with consumer-grade UX without compromising on the speed of application delivery?

Beautiful apps at the speed of business

At WaveMaker, we fully appreciate the role of user experience in the success of enterprise software. That belief also translates into features in our award-winning RAD platform. The following capabilities empower developers to churn out beautiful apps at the speed of business using the WaveMaker low-code platform:

Get started with a free trial of WaveMaker RAD Platform today!

Rapid application development platforms ­– the low-code and no code tools that have proliferated in the last few years – have given rise to the phenomenon of the citizen developer. A citizen developer is someone who is, or can become, proficient in RAD development, either independently or in support of a professional developer.

In the latter case, creating a new app may involve a tag-team approach in which the pro prepares the components that go into composing an app, and the citizen developer can then develop the app. Such two-pass development is one highlight of select RAD platforms.

The citizen-developer phenomenon has gained a wide following in the past few years, essentially because it enables thin IT teams to reduce their backlog of development projects. Another major reason is that citizen developers, once proficient on a RAD platform, can shelve any older development technologies they may have used.

But even with a wide following, the acceptance of RAD has not spiked in use, but instead has evolved from quick and dirty apps (which were more like prototypes) to nice and final apps (offering a great user experience).

As part of that evolution, a number of use cases for RAD emerged. Arguably, the most popular of those are:

RAD platforms are not best suited for developing gaming or other highly interactive apps that use very little data. That would rule out Uber-like apps and gaming apps such as Angry Birds.

RAD is most suitable when the apps are data-driven, 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 in 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. AJAX applications – also called single-page applications, because data is called into a page without need for a server fetch of a new page – provide a better user experience and are hence preferred.

In addition, low-code platforms are well suited for those applications that are created in Gartner’s Pace Layers model: Systems of Innovation or Systems of Differentiation. Low-code platforms are also suitable for Mode-2 development (the Innovate layer), as defined in Gartner’s Bimodal IT model.

As we see a rampant spread of the consumerization of IT (i.e., corporate apps that look and act like consumer apps), RAD is seeing a new growth phase.

The D in RAD has also been redefined in the new era. Today, the D in RAD refers to both delivery and development. RAD platforms have evolved to cover the entire breadth of application delivery. For instance, 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 (for example, through use of containerization technology).

In short, today’s RAD platforms are nothing like their earlier cousins, although the goal of rapidity still remains.

The challenges of traditional development are not new, nor have there been any substantive improvements in traditional languages that would deliver quantum improvement in time to deployment of new apps – where speed virtually always means corporate cost savings, earlier opportunities for app monetization, or both. That dearth of innovation virtually opened the door for a surge in RAD adoption, whether it resulted from need or opportunity.

Originally published by Vijay Pullur, CEO of WaveMaker, in tmcnet.com

I have been talking a lot about APIs and their importance in the present day. You can find out the first 2 parts APIs series post 1 & API series post 2.  

This blog post is a continuation of the same series. I intend to take readers through an interesting read on the relationship between Low-code platforms and APIs.  

As discussed in the last post, there are 3 high-level actions for the API lifecycle,

  1. API Publishing to create and deploy APIs
  2. API Management to manage and monetize APIs
  3. API Consumption  to discover and integrate with the APIs

Typically the actions - API Publishing & API Consumption get done in an app development platform and API Management gets done on an API Management platform.  

In this post, I will address how low-code platforms, as the torchbearers of modern app development tools, have taken the Application Driven Development (ADD)  as a mantra and has made life easier for developers around the world, including citizen developers.

A good low-code platform should be able to enable both API Publishing and consumption and have solid collaboration with an API Management platform as well.  Let's delve  into the details now :

Auto-generation of APIs

For some time now, Low-code platforms have been auto-generating the code based on visual development.  It’s time to do the same for the APIs.  Some of the most common APIs that can be auto-generated can include the services from DB, external services, custom-coded business logic, security services, etc.

For instance, it’s imperative that low-code platforms, at a minimum, should auto-generate CRUD APIs for the associated DB entities.  More advanced platforms can also APIfy the SQL queries and  DB stored procedures allowing total control for the users.

Other services like security and custom code business logic are also great candidates for APIfication.  For instance, if you have a custom coded in your CRM app a function to take return the list of all users from the EMEA zone, then that function should ideally be APIfied, automatically.

Automatic conversion of SOAP to REST

APIs these days are invariably REST-based.  But there are still big remnants, of legacy SOAP-based APIs, and modern low-code platforms would automatically create a REST API endpoint for the app.  This auto conversion is especially imperative in an enterprise setup, where legacy baggage is seen far too often.  The automatic availability of REST APIs is an important step in modernizing legacy apps.  

Easy consumption of APIs in an app

Out-of-the-box integrations and connectors are increasing making its presence in today's market. and a lot of app Development platforms focus on them. But often these platforms do not realize that there is always a custom API requirement for an app. Hence all kinds of integrations - both out of the box and custom should be treated equally.

Ease of design, testing, and sharing in APIs

Another pitfall in many low-code platforms is that they tend to focus a lot on API consumption through connectors and forget about API publishing aspects.  In a connected app world, it is imperative that your own app should have easy ways to create, design, and share APIs.  Inbuilt tools that can design your APIs (for eg, configure path parameters vs query parameters) with ease, test them (through an integrated testing sandbox), and then publish (private, public access) are important features in any other modern low-code platforms.  There should also be easy integration to publish these APIs into the enterprise API management platform so that it's instantly available to the API consumers within an enterprise.

APIs- a tad bit technical.

Modern REST APIs, though simplified, is still quite technical in nature.  There is still technology involved in understanding path versus query parameters, headers, auth headers, API key, etc.  Low-code platforms, which are positioned as app-building tools for business users and citizen developers still find it difficult to work directly with APIs.  A smart low-code platform abstracts these complexities and provides you with a nice UI-based connector to work on.  This is where the out-of-the-box connectors become really helpful.  But even APIs of your own app should also be abstracted the same way.  That is where a 2-pass development approach would be very helpful in terms of creating reusable UI components for the business user.

The above list looks very simplistic.  But a quick glance at various low-code platforms shows you the stark reality. In other words, API Driven Development is still just wishful thinking than a reality among low-code platforms.  This is one space WaveMaker scores far ahead of its competition.  This is one of the features that is going to make you ready for app building in the modern digital world.

Debunking yet another set of myths surrounding the world of apps, with  something very essential for technology and business leaders who are trying to take a decision on apps building in the  modern digital world.  With the demand for business applications outstripping the availability of IT resources, business leaders often find IT as a bottleneck to get their apps created quickly. There is no doubt that business innovation can be fostered by mobile and web apps, but misconceptions about business app development remain and  this in turn  can hamper decision-making. Here are seven myths that can stall business innovation in an organization and let’s demystify them for better understanding

Myth #1:  The bigger the app idea, more the time it takes

“There are no limits to imagination and the size of your idea.  The real bottleneck comes in when the you try to appify your idea.” But wait, that's an old saying. New age low-code platforms which offer you rapid application development lets anyone with an idea to build an app quickly.  There might be some intervention by the technical developers, but that doesn’t hinder the initial process of appification of an idea quickly.  

Myth #2:  Apps with compelling UI/UX is an expert’s job

Professional apps built using traditional methods have a very intuitive user experience.  Usually getting those slick user experiences, associated with a great app, involves senior front-end developers who are good at JavaScript, HTML, and CSS.  But with the new tools based on visual development, out of the box templates, one can do away with UI experts.  The finer adjustments can be done with simple DIY hacks.  The effort is also reduced to just hours to days instead of weeks to months together.  

Myth #3:  Apps created by business users cannot integrate with internal business systems  

Most business apps contain data from back-office systems or specific business applications like ERP. Connecting an app securely to these often-legacy systems requires access and integration logic. IT can manage and provide access to these systems via APIs, through API management solutions,  in a secure, reusable, and reliable way. Business users in turn can consume these APIs through low-code platforms like WaveMaker, to intuitively integrate and use them inside an app.

Myth #4: App’s security and DB need expert intervention

Professional apps usually have complex DB design, professional security and coded as per standards.  In traditional development, these qualities cannot be achieved without the involvement of expert developers.  But with new tools and technologies—including automatic table creations, visual DB design, and configurable security means, anyone can build apps and they are almost codeless. This is ideal for business users, product managers, and in general any citizen developers.

Myth #5: Business apps will not be supported by IT

Apps are of multiple types.  One of the categories is core apps that drive the company’s core businesses. And then there are a lot of other apps that are categorized as long-tail-apps scattered all over the organization and are usually those that are driven by business teams.  Traditional IT support only the core apps, and the long tail apps flourished under the shadow of the IT teams.  However modern IT leaders also bring under their control long-tail apps to curtail shadow IT in the organization.  This is done using modern app development platforms that allow centralized control by IT and also ease the building of these apps by business users.

Myth #6: Modern App Development Platforms Are Closed and Proprietary

This is a myth that is almost true. The new-age app development platforms that offer low-code and rapid application development are mostly closed and proprietary.  However, there are few platforms like WaveMaker, which are based on open standards and offer the developers a choice to move away from the platform with the auto-generated app code, which can be migrated and developed in any IDEs like Eclipse. Though there is an understandable fear that developers will get locked into something that they may later want to move away from, these platforms will provide the flexibility that allows developers to make any real-time changes needed.

Myth #7: Cross-Platform Apps Are not fully featured

There is a misconception that cross-platform apps, usually built using hybrid mobile app development, cannot support a lot of features.  It’s true that not all platforms are equal and some may not support the full plethora of feature development, but it's still possible to develop apps that are rich in functionality. Some platforms for example - the RAD platform by WaveMaker make it easy to build apps that have features customized as per business requirements.

Recent times have seen the emergence of many enterprise application platforms that have the capability to address these challenges and make app development work much less tedious than it appears. The WaveMaker platform is one such platform worth mentioning. This platform develops & Deploys custom apps with multiple functionalities in a cost-effective and less time-consuming manner.

As an Architect for WaveMaker, I have come across multiple IT environments.  They are getting more and more complex by the day, in spite of all advances with cloud computing and deployment options. IT Environments in large complex organizations are typically dispersed and have multiple silos as shown in the graphic below.

In addition, sub-groups typically have their own processes and technologies. This makes integration across organizations and the centralization of IT applications a big challenge.

This problem gets aggravated with each M&A activity. Acquisitions provide a great opportunity for innovation with the possibility of integrating assets of different organizations. But different technologies, systems, and processes hinder the realization of these opportunities.

Consolidation of IT for these organizations is a good position to be in as shown in the graphic below. But it is not trivial to achieve. More than the technology, managing resources, skills, and practices across organizations become bigger challenges.

Now, what if we can achieve integration of these different systems without actually consolidating IT systems?  What if different existing systems can co-exist while realizing the benefits of consolidation? How would you go about doing it?

Step 1: Ensure all systems are API-enabled

If you want to make your application future-proof, there is no other alternative other than to build APIs. How to make different types of applications API enabled, is a topic for another blog.

Let’s look at the organization now in the graphic below.

So what has changed?

Now, every system is open for communication. There may be different systems using different technologies, but they can all talk to each other with a common simple language. APIs.

As we have all the systems accessible, what next? How do we consolidate the information from here?

Step 2: Consolidate endpoints with API management

You must have looked at API management from the point of view of identity, authentication, rate limiting, throttling, metering, etc. But to make the best use of internal APIs, we need to transform them,  aggregate them, and cache them where needed.

Take an example of an application like Kayak. They aggregate APIs from multiple airlines.

Similar is the requirement of a complex organization. Think of your large organization as vendors across multiple silos. Would you not like to manage all your vendors from a single place?

Current API Management products need to evolve to meet these challenges. API Management technologies, for most of their life, we're geared to public APIs that you wanted to monetize. They have also been priced by traffic usage. Recently many of these API Management vendors have started focusing on these internal enterprise APIs.

The graphic below shows how an API management platform is consolidated.

After the end of the second step, you are in a state where you have consolidated endpoints. A happy, future-proof state to be in. But this also means they need applications using these APIs. Not only the IT systems but multiple potential applications waiting to integrate these APIs to speed innovation to a different level.

Step 3: Enable rapid application delivery

With so much information available, you clearly can think of many more applications, than your IT can develop. Coding is time-consuming. The current trend is to go for ready-to-use components than to write them from scratch.

Going a step further, you don’t want to fall into figuring out the integration of these ready-to-use components either (boilerplate code). Developers with minimum technical/UI skills should also be able to deliver applications. But that simply increases the risk of poor quality applications.

This is where a low-code rapid application delivery platform can help you generate consistent beautiful-looking applications. Reusable widgets, styles, and templates are provided by the UI experts and other developers can simply use them with drag-drop features.

In summary, I have shown you a path to consolidate all your silos via APIs, manage them using an API management tool, and finally build innovative apps much more rapidly.

Interpreting the Stack Overflow 2016 Developer Survey results from an application delivery perspective

Stack Overflow recently announced the results of their annual developer survey. This year, over 50,000 developers in 170+ countries answered 45 questions ranging from the programming language they use the most to whether they preferred Star Wars or Star Trek, and everything in between. Maybe that is why they call it “the most comprehensive developer survey ever conducted.”

The survey provides insights into popular technologies, diversity, compensation, and sci-fi preferences. You can go ahead and get your geek on with the survey results here. But in this post, we will interpret the results from an application delivery perspective, focusing on the technologies and challenges.

Front (end) and center

First things first, JavaScript overtook Java as the most popular tag on Stack Overflow. In fact, all the front-end technologies have gained popular ground. With consumers demanding engaging experiences across different devices, front-end and mobile technologies will only grow more popular. I'll go out on a limb here and make a prediction that next year Android will overtake Java to become the second most popular tag on Stack Overflow.

The rise and rise of AngularJS

AngularJS now seems to be the go-to web application development framework. In just a few years, its popularity has skyrocketed and it appears to be the dominant JavaScript framework out there. The Stack Overflow survey results corroborate this fact as AngularJS appears multiple times in the top technology combinations preferred by front-end developers.  It also figures prominently in the technology combinations of full-stack and back-end developers. Even among developers who are not developing with the language or technology, AngularJS is one of the top 3 technologies that they would most want to work with.

Looking back, WaveMaker made a prescient choice by rebuilding its RAD Platform a couple of years ago using AngularJS. For those who are new to WaveMaker, versions prior to Studio 7 were based on the Dojo framework.

Challenges to application delivery

Amidst the rapid technological changes, the challenges to application delivery remain and continue to put pressure on IT to deliver applications at the speed of business. As per the Stack Overflow survey, developers cited the following challenges at work:

Sounds familiar isn't it? One way to broadly categorize these gripes would be under:

Do share what, according to you, are the challenges and solutions in the comments section.

Traditionally RAD has referred to Rapid Application Development, a way of building applications that contrasts with the more formal Waterfall model. As you would expect, RAD produced results quickly using tools that generated the application code from a high-level description or definition (in other words ‘software design specification’). Readjusting the design specification meant the application could be regenerated, thus saving time needed to rebuild the application to accommodate business changes. So, as a corollary, RAD supported Enterprise Agility.

Shortcoming of Rapid Application Development

Such code (re)generation from a model or specification was done using code-generating tools* that focused on database applications - and that includes a lot of applications. The generated code was rarely as good as the code written by a skilled human programmer. But really, many applications did not need hand-crafted code.
The perceived need for highly performant code confined RAD tools to prototyping, and away from final production (real-life) applications. The generated code was hardly readable and very difficult to maintain. Neither could such code be taken into professional development tools (the modern-day IDE) for enhancement. This was a real blocker for writing production-grade applications.
Code-generation was really a tradeoff between how quickly one can hack an application together and the resources it needed at runtime. Indeed, the need for constant business innovation was changing the speed at which enterprise applications were being thought up and written.

RAD for live apps gaining acceptance

Two important factors have started to tilt the balance in favor of RAD or generated code: (1) consumerization of IT or increasing importance of user interface (experience), and (2) adoption of the cloud model or scaling through commodity hardware.
1. UX Factor. Good UX can be the main difference between a hugely successful app and a complete failure of an app in the hands of intended users.

Good UX balances amazing looks, engaging experience, and ease of use. These are not easy for developer teams to build into apps, neither is it natural for them. But with the changing profile of employees and customers, most enterprises are realizing the importance of front-end focused applications, and tools that could help achieve good results quickly.
2. Cloud model. The crashing cost of computing and storage means the primary concern of software development is no longer hardware scarcity and optimized resource utilization. Cloud platforms built on commodity hardware and horizontal-scaling designs have further relaxed the need for handcrafted and highly performant code.

Rapid Application Delivery is the new RAD

The factors that lead to the increasing acceptability of Rapid Application Development (RAD) point us to the inclusion of Rapid Application Deployment as an important supplement. This changes RAD to Rapid Application Development and Deployment (RADD), or simply Rapid Application Delivery (the new RAD).
This renewed interest in RAD is reducing time to deliver new apps – the time between when a business feels the need for an app and the time it is ready to use. A successful RAD platform may have to focus on all 3 elements involved in the delivery of applications: Development, Integration, and Deployment. Also, RAD tools need to assist in getting the UX to finish.

* Quoted from the book “Code Complete” By Steve McConnell. More here at Chapter 30.