Categories
Insights

Increase speed of app delivery and reduce costs – WaveMaker

In my role in business development, I have an opportunity to talk directly with a number of stakeholders who are looking for help to modernize existing apps or build new ones to meet their business goals and increase pace of innovation. But given their existing investments in application frameworks, architecture and legacy code, they take a very cautionary approach when it comes to migrating apps to the cloud. They fully understand the benefits of moving their apps to the cloud and how that will increase speed of app delivery and in reducing costs for the long-term. In this blog, I have laid out clear and practical strategies to help with cloud migration.

First, let us consider the key question of app development before they are deployed in the cloud. To use the most modern trends in software development, it is best to go with a visual application development tool for quickly assembling apps using pre-built widgets, themes, layouts, business components and more. I would also highly recommend going with an API-first approach when building apps to enable omnichannel consumption of data and services. And lastly, when it comes time to deploy these apps, take one of the 3 cloud-first strategies that I have laid out here.

Cloud-native Strategy

  • With this strategy you are truly taking a Cloud-native approach. You not only assemble and build your apps in the cloud, but also do your testing, improvements, maintenance and deployment in the cloud. There is nothing on-premise with this approach
  • This strategy works beautifully if you are building new applications or enhancing applications where the data and services consumed by your apps are accessible in the cloud (and not behind firewalls) both during development and runtime
  • WaveMaker offers a SaaS offering for visual rapid application development and deployment. This platform allows for rapid prototyping, testing and iterating on your apps in an agile manner. The deployment is a PaaS offering build on Docker technology. WaveMaker SaaS is optimized for building and running applications in the cloud.

Cloud-optimized Strategy

  • In this strategy, you are leveraging benefits of the cloud while having a complete control over data and services consumed by your apps running in the cloud
  • This strategy is preferred by bigger financial and insurance companies who are somewhat averse to running vendor tools inside their own data centers for security and compliance reasons
  • With this approach, you are running vendor development tools in a public or private cloud while you develop your apps and allow access to data and services via a secure network
  • WaveMaker Enterprise platform can be run inside a public or private cloud (virtual private cloud) for rapidly building applications. Once built, these apps can be deployed in your public or private cloud. Access to data is via a secure network and may reside in either your own data center or private clouds

Cloud-hosted Strategy

  • This is an hybrid approach for migrating apps to the cloud. In this strategy, you develop and test your application on-premise, but deploy those apps in the cloud
  • The apps build on-premise can be deployed to any private or public cloud and use any 3rd party web containers
  • WaveMaker Enterprise offering allows on-premise development of your applications. Since the apps are developed inside your firewall, there are no security and compliance issues. Deployment of apps happens in either your private or public cloud, in both cases access to data is via secure networks and residing in your own data center or private clouds

As you can see in all 3 strategies, you have migrated your apps to the cloud, which is a very big first step in modernizing your applications and making them omnichannel (accessible and responsive on both web and mobile devices). With these strategies, you are future-proofing your apps for changes in technology, devices, and most importantly increasing the speed of app delivery while reducing long-term total costs of building and maintaining applications.

Categories
Enterprise Application Development

The Hawk Hill View

Low-code Application Development vs Traditional Development

Hawk Hill is one of my favorite places. When you sit there, you see the sea on one side and the bay on the other.  You can clearly see the change of pattern in the water between the two sides. The bay shows the calm waters while the sea is full of waves. This view is awesome as it show the two bodies of water at the same place (of course, the majestic view of Golden Gate is present as well).

I was in a similar situation some time ago when our team was developing functionality for appointment scheduling for a popular retail chain.

On the one hand, we had their website written with  traditional architecture and practices. And on the other, we created application for appointment scheduling with our low-code platform. The comparison of traditional and modern RAD development never looked so enlightening before.

About the application

Appointment application included:

  • Creation of the appointment functionality
  • Google Calendar for appointments in the backend involving store and email notification of events
  • Presentation of these appointments to the store salesperson on mobile devices (As an application in the micro-app container provided by SpotCues)

Screenshots of a few representative pages

The solution also involved changes to the existing website including:

  • Adding buttons with right styles to the website  and optimizing it for different devices
  • Launching the appointments functionality in a pop-up
  • The dialog then needs to be sized correctly based on the device it is viewed on
  • Content from the website application needs to be passed to appointments applications for locations and other details

The solution took around 6 weeks to delivery. But it clearly presented the comparison of 2 development methodologies.

Proposal and Requirements

For the proposal, we created a simple prototype of appointments functionality within a day

  • Simple online database backed storage
  • Micro app for listing / filtering / searching the appointments based on location of the store
  • Email based notification to the user and store manager
  • Responsive view on all devices

All of the above was done using the ready to use RAD components.A real working prototype of the application presented good clarity. The proposal was quickly accepted by the customer with a very few changes.

Implementation –  A smooth sailing

The appointment application functionality was implemented with great looking multi-device UI and  Google Calendar based backend and notifications. This also included authenticating with OAuth2 and using Google Service Account for calendar service.  Ready to use RAD connectors were utilized to reduce the code.

Application was developed for listing/searching/filtering the appointments using reusable card layout and reusable styles. This is used by the store persons to view the schedule in a micro-app container provided by SpotCues.

This was all built using RAD and was available in three weeks. Reuse of readily available connectors, UI components and styles generated a modern application with APIs enabled and multi-device responsive UI.

Integration and Delivery – Challenges begin

Non availability of resources, specifically UI developers

The website changes were expected to be built by the customer’s IT team. But they were already under a lot of other work related to the website. Non-availability of IT team specifically the UI developers to make the relevant changes is not a new challenge.

Coding is time consuming

Our team was tasked with the changes to minimize integration efforts on customer side. The buttons, styling and multi-device behaviour were all supposed to be handled in a jQuery script. This was all manual work. We ended up spending substantial amount of work in that. Three  weeks were spent just on the integration efforts.

APIs makes your applications future proof

A lot of information needed to be passed to the appointment application. APIs could have been very handy in this situation. Appointment application could have requested information about locations and hours of the stores to the website API, if they were available. But unfortunately, the website application was but with Java Server Faces (JSF) and no APIs were available. A lot of scraping logic needed to be built which not only increased the time but also provided a solution inferior in quality and maintainability.

Codebase for multiple devices

The script handled code to generate styles for different devices. This was duplicated for different screen sizes to adjust the size of the dialog and other related things. The default application built with RAD if rendered as is,  would have served well for all devices by default.

Larger QA cycles for handwritten Code

Hand coded script code took more than double the time in QA. Hand written code comes with its own uncertainties and manual errors. Generated application on the other hand had most of reusable components well tested and ready to go.

Micro services based design help with faster delivery

The website was single monolithic application. The release of the appointments functionality was completely tied to the release of the website. Release of the website itself was stuck on a lot of other issues not related to the appointment applicatication. A Micro service based design of the website  could have helped with continuous delivery.

Summary

Working on the edge of a traditional and modern low code rapid application clearly presented the benefits we can achieve with later. Modern RAD provide great looking multi-device UI and autogenerated backend and connectors to slash the development and QA times. Micro services and automated delivery options enable you to release much more frequently. Of course, we will also try to automate such integrations with our RAD platform in future based on this experience.