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 protoyping, 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. Crashing cost of compute 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 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 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.
WaveMaker hosts applications for thousands of users built using wavemakeronline.com. Keeping promise of free hosting upto 300 days wasn’t a very easy target. Even the smallest of VMs would not have been economical enough. This is when, a year and half ago, we explored containerization and saw that Docker was trying to provide very usable tools for containerization. We were able to break instance in smaller partitions using container technologies and accommodate many more users on the same infrastructure. Also as containers provide a lighter form of virtualization and can be launched in a few milliseconds, we could start the whole container on a user web request. This led us to further optimize the deployments by passivating the application not being used.
Building this platform provided us a lot of learning, which we want to get to the enterprises. Docker based infrastructure provides containers, which can be shipped to different environments with minimal effort and configuration. Though, enterprise finds it challenging to leverage these technologies as these are still scattered.
WaveMaker Enterprise, provides an enterprise solution, which can help enterprises save this complexity and achieve advantages including simplified and automated application delivery, optimized resource utilization along with other enterprise features including monitoring on all levels, role based access control, release management, data backup and recovery etc…
What WaveMaker Cloud offers
For an idea on what WaveMaker Cloud offers you, take a quick look at the WaveMaker Cloud page. Let me list down the top features for the sake of completeness of this post
– Docker architected private cloud with Optimized Resource Utilization
– Micro-service Architecture for application deployment with easier versioning and upgrades of application and platform.
– IT Certified Software Stacks provisioning and configuration
– Continuous Delivery with reusable Software Stacks with minimum configuration.
– Comprehensive monitoring and management of applications, containers and infrastructure
How does it all work?
In a Micro Service Architecture based application deployment scenario, these are typically the steps followed:
1. IT Administrator creates the private cloud environment either using infrastructure from their data center or from IAAS providers.
2. Enterprise Architect defines the various micro services and their software dependencies for deployment.
3. DevOps Engineer then is responsible for hardware provisioning from the private cloud for all the services defined by the Enterprise Architect and deploy services.
In the world of WaveMaker Enterprise Cloud, the above steps translate into the following steps…
1. The IT Administrator easily creates a Docker based Private Cloud infrastructure using WM Cloud’s DIY based cloud management console.- He will create shards, to represent dev, staging & production environments,- Add physical instances to it, where containers get provisioned. The shards are available for selection when the applications are getting deployed
2. Enterprise Architect creates an Application Stack which represents the collection of configuration details of all the micro services (Services). The Service itself would have been created by either by the EA or a team of app developers working on that particular micro service. The service configuration can contain one or more software components called Packages, that defines it. For example, a web service can have the packages of Apache Tomcat and Java run time.
3. DevOps will use the service configurations and the package definitions are snapshotted as a Docker Image which is stored in a Private Enterprise Registry. DevOps is also responsible for configuring the provisioning requirements for each of the service. These requirements range from selecting the size of container (viz. XL, L, M, S) to the number of containers per service for scalability.
In the action with WordPress application
In this post we will see how to quickly setup deployment of a WordPress application and replicate them consistently with minimal effort and configuration.
Let’s start with some terminologies.
Any application can be deployed to one or more environments referred as Application Environment. These can be configured for different stages of application delivery e.g. staging, production etc.. or these can also be some other environment as customer dedicated environment etc..
Application Stack represents a reusable deployable application with all its services in a logical group. This can be deployed on more than one application environments expediting application delivery. Minimum configuration is required for deploying an existing Application Stack on different environments. An Application Stack may consist of multiple services.
Services / Images
A Service (Image) represents a micro-service in the deployment of an application. E.g. MySql , Apache2 can be 2 different services in an application stack. A service is based on an Image which consists of multiple packages. Image actually maps to a DockerFile. It requires may require some configuration variables which can be supplied when the Application Stack is configured in a new Application Environment.
A service consists of multiple packages. E.g. a Tomcat service will need Java and Tomcat packages. Other than that a package in WaveMaker Enterprise can also specify the configuration variables needed at runtime. The values of configuration variables can be provided when Application Stack is deployed on specific environment.
A Package can easily be configured with a few scripts in WaveMaker Enterprise. Existing scripts can be used to create a package.
Base Images and Private Image Registry
A service (Image) can be created on the top of one of the base images. Base images are Docker images hosted in private image repository in an enterprise. A new base image can be downloaded from Docker repository, or can also be created and uploaded to private image registry.
Illustrative Example using WordPress Application
In this example we will take a simple case of deploying a WordPress application on WaveMaker Enterprise. We will simplify it to use only one service consisting of packages Apache2 with PHP, MySQL, and WordPress. You need to have WaveMaker enterprise installed and need to register as a valid user to it.
Let’s create the packages first.
Provide information including name of the package, version. Other than this vendor and OS which will run this package can be provided.
You can specify the files needed for the installation, configuration and start of this package. These files can be the script files that you need to execute, of the other required files for the package. They will be uploaded to a directory with the name /wm/<packagename>, where packagename is the name of the package you specified in the previous step.
Other than this we need to provide the commands to add these packages. The following are the commands
Installation Commands [Executed during installation]
chmod 777 /tmp && apt-get -y install mysql-server-5.6 mysql-client-5.6
Configuration Commands [Executed during configuration, uses the value configured for configuration variables during Application Environment creation, e.g. MYSQL_ROOT_PASSWORD]
#Permit Root User to Login
sed -i -e"s/^bind-address\s*=\s*127.0.0.1/bind-address = 0.0.0.0/" /etc/mysql/my.cnf
#change root password, the password value is taken from env property named MYSQL_ROOT_PASSWORD
mysql -uroot -e "GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION";
mysql -uroot -e "UPDATE mysql.user SET Password=PASSWORD('$MYSQL_ROOT_PASSWORD') WHERE User='root'";
mysql -uroot -e "FLUSH PRIVILEGES";
Startup Commands [Executed to start the package component. E.g. MySQL in this case.]
In this step you specify the ports that needs to be exposed for this service to be consumed. Also the configuration variables required by the package needs to be added in the Required field. E.g. MYSQL_ROOT_PASSWORD in the screenshot above.
Exposed configuration variables are those set by this package and can be consumed by other packages in the service. E.g. JAVA_HOME can be configured by installation of Java package and can be consumed by the dependent packages.
Apache2 with PHP
# apache installation
apt-get -y install apache2 libapache2-mod-php5
apt-get -y install php5-mysql pwgen php-apc php5-mcrypt
sed -i "s/KeepAliveTimeout 5/KeepAliveTimeout 300/g" /etc/apache2/apache2.conf
Specify port Http/80 and https/443 on the configuration page.
# Install WordPress
wget -O /tmp/wordpress.zip https://wordpress.org/latest.zip
# db creation for wordpress requires env properties such as MYSQL_ROOT_PASSWORD, WORDPRESS_DB_USER, WORDPRESS_DB_PASSWORD
mysql -uroot -p$MYSQL_ROOT_PASSWORD -e "create database wordpress";
mysql -uroot -p$MYSQL_ROOT_PASSWORD -e "CREATE USER wordpress@localhost IDENTIFIED BY 'wordpress123';"
mysql -uroot -p$MYSQL_ROOT_PASSWORD -e "GRANT ALL PRIVILEGES ON wordpress.* TO wordpress@localhost;"
mysql -uroot -p$MYSQL_ROOT_PASSWORD -e "FLUSH PRIVILEGES;"
cp wp-config-sample.php wp-config.php
sed -i "s/database_name_here/wordpress/g" wp-config.php
sed -i "s/username_here/wordpress/g" wp-config.php
sed -i "s/password_here/wordpress123/g" wp-config.php
chown -R www-data.www-data *
Now we need to create Service /Image with these packages.’
Let’s create image with name wordpress choosing base image of Ubuntu 14.04 and provide it a version 1.0.
Now add packages we created to this Image and order the packages in the right order by simple drag and drop. WordPress Package is kept in the end as it will depend on the other 2 packages.
You can see the DockerFile generated for the Image. Also other scripts involved can be looked at.
You can see the logs of Docker Image build and push.
After this we can configure a service from an Image providing the default values for the configuration properties. These properties can be modified later while configuring the environment.
Now let’s create a reusable Application Stack
You can create an Application Stack by selecting the services you need to add. We are adding WordPress Service we just created here.
Instantly provision Environment with the WordPress Application Stack
Provide a version, application stack, and shard to which we need to deploy WordPress application. As we saw earlier shards were configured by the IT Administrator for logical slicing of the enterprise cloud. Please select the default shard here.
Also we need to provide number of nodes and the strategy for balancing the load. I am choosing simple Round Robin strategy. Container type will decide the size of resources available to WordPress application.
We can configure the server URI for application deployment.
Values of configuration variables can be modified here for environment specific values.
Ready with WordPress Application
Access the application on https://wordpress.demo.nwie.net/wordpress/index.php
We saw in this blog, how simple it is to create a reusable application stack and deploy it in any environment with minimum configuration. This really provides great optimization and continuous deployment of enterprise applications saving long release cycles. Please contact firstname.lastname@example.org for demonstration and more information.
A common request among WaveMaker Studio developers is to integrate third-party UI widgets inside WaveMaker Studio and make them available as drag-and-drop components. This task becomes especially challenging when we consider the fact that the WaveMaker Studio uses AngularJS technology for defining its widgets and the third-party widget may be using another technology like jQuery. In this blog post, we will take a use case-based approach to see how a jQuery-based third-party widget is integrated with WaveMaker Studio. For achieving this, we will leverage Studio’s very own superstar component – Prefab – and demonstrate its power of customization.
Lets take Lightbox image viewer widget and see how users can integrate this widget into WaveMaker Studio using Prefabs. This widget is jQuery-based and this link gives the details about how to use the Lightbox widget in general.
Steps to integrate Lightbox widget into WaveMaker Studio
The detailed steps to create this Prefab, export it and use it any WaveMaker Studio project are given below.
1. Get the widget library source code: Download the Lightbox resource files from here and unzip it into a folder
2. Import the relevant js, css and image files into WaveMaker Studio. In case of Lightbox widget, the details are given in the step-1 of “How to use” section in the Lightbox project home page.
The imported files can be seen under the folders js, css and image.
3. Set the Bindable Properties for the Prefab: Go to the newly introduced “Prefabs Properties” section under the project “Settings” and add references to the imported js under script section, css under the style section and an icon file. Add the bindable properties that are needed for this Prefab. In this example, we have added “image” and “title” properties that represent the location and title of the image to be displayed.
These properties will appear in the properties panel of the Prefab, once it is drag and dropped into the WYSIWYG canvas.
Checkout the WaveMaker Prefabs documentation to get complete details about this new feature.
4. Design the Prefab UI: Drag and drop the “picture” widget to display the image thumbnail and bind the “Hint” and “Source” attributes to the “title” and “image” properties respectively that you had defined in the previous step.
And finally, step-2 of “How to use” section of Lightbox documentation instructs the user to embed the images inside an anchor tag(<a>…</a>) & also add a “data-lightbox” attribute, to activate the widget. In the Studio we can do this by adding the above details in the “Markup” section, as shown below.
5. Export the Prefab using the Export menu item in Studio (see Fig-7). Make sure you have tested the Prefab before you export it.
6. Import the Prefab and use it as any other component inside an app. To demonstrate the Lightbox Prefab usage, lets create a demo app called “ImageViewer” and import the Lightbox Prefab. Once it is imported you can spot the LightboxPrefab in the Prefabs accordion section.
7. Perform the following customary steps in the Studio to integrate the LightboxPrefab:
a. Import the sample DB provided with WaveMaker Studio
b. Drag and drop a Live-List widget into the canvas and bind it to the dataset of “HRdbEmployeeData” live variable that got created automatically after import of sample DB.
c. Delete the “panel1” created under the “listtemplate1”.
d. Drag and drop the lightbox prefab into the “listtemplate1” and bind the image “Source” property to “Variables.HrdbEmployeeData.dataSet.picurl” and the title to “Variables.HrdbEmployeeData.dataSet.firstName”
We are all set now. Run the application and see how the Lightbox image viewer functionality executes successfully.
The above approach of using Prefabs can be applied successfully to integrate any third-party UI widgets into WaveMaker Studio instantly, providing the needed customization inside Studio.
Try it out with your widget of choice and let us know how it went. Send your experience of integrating your custom widget to email@example.com.
Product & Customer-Success Manager
The previous post in this series, discussed issues confronting an enterprise and how they translate into the need for building innovative applications, and here is an outline the sandbox that could meet this need.
While it is easier to understand the need for innovative business applications, enabling their development in an enterprise is not easy. Let us explore four major factors that shape an enterprise innovation platform.
Speed: An enterprise innovation platform should enable applications to be developed quickly, integrated with data sources or System of Records in the company, and deployed for ready use by business. While speed of application development is important, it is also necessary to get the user experience and scalability right – two traditional time consuming elements.
Ideation: Innovative applications need ideas, inputs, and participation from many different people in the enterprise, even during stages of development. While most developer tools are not accessible to business users and those beyond IT, a collaborative environment provides an opportunity to the company to innovate faster.
Involvement: Apart from critiquing and suggesting improvements post facto, it might be good to involve business users early on in application building. The innovation infrastructure should provide a way for “citizen developers” (business-user-developer) in the company to compose applications using thin software staff.
Evolution: Really, no one knows exactly, and it cannot be pre-determined, what applications are needed for the company to succeed through innovation. At times the specs are unclear to start with or can only become clear when the application (and its underlying intent or strategy) is used in the market. That means, the innovation infrastructure must be designed for multi-round evolution of application with zero hindrance to change and always open to chance.
The Sandbox should obviate ‘Shadow IT’
Business users and software developers are not happy at the pace of innovation in their companies and find it hard to understand numerous processes and limitations that prohibit them from moving faster. In some cases, this results in ‘The Shadow IT’. While the intent may be good, the path may prove not to be.
Internet is full of stories of things gone wrong with Shadow IT. The worst of all is when sincere efforts at innovation end up in wasted resources and frustrated talent.
This necessitates an IT-sanctioned platform that not only encourages enterprise innovation but also makes innovation application projects effortless as much as possible.
How the Sandbox makes it easy
The speed and ease of development of apps is the key to enterprise innovation infrastructure (the Innovation Sandbox). Replace traditional methods of long-drawn software projects (possibly through an RFP process) with Rapid Application Delivery (RAD).
Speed of development is important, but not at the cost of user experience of the application. This is important, as every user (including employees of the company), is influenced by the great apps of the consumer world.
Therefore this sandbox environment must enable wider section of the enterprise to participate in building applications and not be limited to highly professional developers.
Any enterprise application has to integrate with important data stored in the company’s System of Records (applications that hold key data) and perhaps with Systems of Differentiation (applications that automate processes).
Enterprise application integration is achieved rapidly when such integration is done through Application Programming Interfaces (or APIs). The simpler architecture of REST APIs and learnings from the consumer web are finding widespread adoption in the enterprise.
Building an app for scalability is a challenge that can slow down any development team. Gradual decline in hardware pricing and increasing power of commodity hardware means developers no longer need to build software for hardware scarcity, they can assume a scalable platform underneath.The sandbox has to enable designing for the cloud, where applications are built to horizontally scale (through addition of computing resources as needed at runtime, without the need for software changes).
An IT-administered private cloud (under IT control, flexible on-demand provisioning and enterprise data-safe, hence private) needs to power the enterprise innovation infrastructure to remove dependence on IT for provisioning computing resources and reduce wait times for apps to become available to business users.
Innovative applications cannot be conceived and built in isolation. The wider the participation, the higher the chances of innovation in the enterprise. Collaboration tools integrated into the development process improves visibility of apps being built, API design and coordination within the team as well as outside.
While the sandbox should be a simple, fully-integrated environment, the task of managing such an environment is obviously complex. Doing this complex job of configuring, managing and monitoring this system, needs powerful and integrated management tools.
Sandbox means freedom
The Sandbox for enterprise innovation (new piece of software running on IT-sanctioned environment) should provide the essential freedom from issues that confront today’s enterprise app development teams. The picture above captures the essential ingredients of such an infrastructure. Clearly, to think outside the box is to think rapid development, to think Cloud and rapid integration through published APIs.
As Peter High, the author of “World Class IT: Why Businesses Succeed When IT Triumphs” says “Infrastructure excellence separates proactive organizations from reactive ones.” Creating an innovation sandbox for their enterprise is fast becoming an important responsibility of the CIO office.
APIs have evolved from just being the building blocks of an application to become the core part of a business strategy of an enterprise. Marc Andreessen’s words – “Software is eating the world” – is true for macro level business changes, but the real enabler for the software are the APIs working silently, behind the scenes to connect apps and devices together. Forrester calls this as “APIs become the digital glue” and lists it as a top technology trend to watch for 2014-16. In the modern digital world, APIs have become the fulcrum for both business and the apps that drive the business.
Characteristics of an API
In API lifecycle there are 3 primary roles: API Publisher, who designs and deploys the API, API Gatekeeper, who manages and monetizes the API and API Consumer, who discovers and integrates with the APIs. Each of these API roles have multiple functions associated with them and those functions define the characteristics of the API. (See FIG-1)
WaveMaker Studio enables app developer to play the role of an API Publisher and API consumer, within the context of application being built. The role of API Gatekeeper is exercised in WaveMaker Gateway, a module that is planned to be integrated with WaveMaker Enterprise platform and is available in the upcoming releases.
What does API-driven App development mean in the context of RAD?
In traditional development approach, an API driven development methodology advocates that the front-end developers take control of the API design and build mocks, while the back-end developers use the API specs to concurrently implement tests and the back end business logic. This paradigm is applied to Rapid App Development in WaveMaker Studio, where the back-end services and front-end development is done concurrently based on the auto generated API contracts. However RAD tools should additionally have features to design APIs for business needs, to configure APIs for access and finally to publish these APIs to be consumed.
API Designer in WaveMaker Studio 7.1, provides a native integrated solution within the WaveMaker Studio to ease the process of designing, creating and consuming APIs within the context of a WaveMaker application. All the characteristics of an API as defined in the previous section will be addressed by the API designer and with ease. Lets jump in.
Say Hello to the new “API Designer” pull out in WaveMaker Studio 7.1
Currently WaveMaker generates REST APIs using Swagger based contracts for the following WaveMaker Studio back-end services
1. Database Service
2. Java Service
3. Web Service
Also WaveMaker generates standards based REST annotations for the above services, which are understood by API tools for generating API documentation. Look out for a detailed blog post on all the auto generated API components in WaveMaker Studio.
Lets see how API Designer eases the process of using APIs as a publisher and consumer.
As an API Publisher: Design, Test & Publish APIs
Lets take a simple use case where the API publisher wants to publish an API to get a list of departments in the enterprise. You can import the sample database provided with WaveMaker Studio to quickly test this. Currently WaveMaker generates Data Access Objects (DAO) with CRUD based REST APIs for every table in the database schema. WaveMaker also generates REST APIs for all the custom SQL queries that user creates. The various end points corresponding to all the tables imported into the data model and their respective REST APIs are shown. See FIG-3, which shows a few CRUD based REST APIs of the “Department” endpoint.
You can further update the design of these auto-generated REST APIs by configuring their description, visibility, method types, parameter type etc.
For instance in FIG-3, user is configuring the visibility of the GET method of the “Department” end point. The visibility options available to the user include the following:
° Unavailable- API is not visible even within the app
° App-Only- API is visible only inside the app
° Private- API visible to all the apps inside the Enterprise Developer Network(EDN) 
° Public- API visible external to the enterprise 
Java Services APIs have additional configuration options like the parameter types and method types. Currently all the methods defined inside the Java service classes are automatically exposed as REST APIs that can be configured further. For instance, if there is a Java service that is created for email services and receiveMail() is a method in that service, this method is automatically exposed as a REST API. In our example, receiveMail() method has 3 parameters “emailId”, “count” and “unread” (to get only unread mails) and the expected REST API definition looks like this:
The above (FIG-4) given REST API definition can be easily configured using the API Designer as follows (see FIG-5):
Once the REST APIs are defined successfully, the next step is to test the APIs instantly using the “Test” tab. Lets refer back again to FIG-3 and test the GET method of the “Department” end point, as shown in FIG-6.
Assuming that the API testing was successful, the next step is to publish the API . Publishing the API would make it available for consumption in others apps, based on the visibility (see FIG-3) that was set earlier. In WaveMaker, API publishing is done along with the 1-click deployment of the application as shown in FIG-7
As an API Consumer: Discover and integrate API into the app 
The integration of Enterprise Developer Network(EDN) with API Explorer inside the WaveMaker Studio, makes it really easy to discover APIs in other apps shared in the EDN and consume them. You can easily browse through the shared APIs, select the API and then import using WaveMaker’s interactive web-service import infrastructure. For instance see FIG-8, where the DELETE method of the “Employee” end point in the HRMS app, shared in the EDN, is tested and imported.
EDN DevPortal 
Now that the API Designer feature in WaveMaker Studio has eased the functions associated with the API publisher and consumer, the next logical step is to enable the DevPortal integration with EDN. DevPortal icon in the EDN home page (see FIG-9) will now take you to the DevPortal API Explorer where you can see all the apps in EDN and their respective APIs and it allows you to further discover, test and collaborate on these APIs.
WaveMaker is working to provide a complete end to end API driven app development approach through WaveMaker’s Enterprise Platform. API Designer is another big step towards this goal. Keep watching this space for a host of planned features, in future WaveMaker releases, which includes API deployment, consumption, 3rd party APIs integration and also WaveMaker Gateway, a new module in the WaveMaker Enterprise platform that will give a full fledged API experience for the users.
 Not available in WaveMaker 7.1. Planned for future releases.
Product & Customer-Success Manager