Our Experience with Migrating the Brightwork Explorer Application to AWS

Executive Summary

• We migrated our application Brightwork Explorer to AWS.
• We described our experiences with AWS and what it means for future application migrations.

Introduction

Brightwork Research & Analysis recently engaged in a development effort to create an application that could help companies monetize forecast error (rather than using the typical forecast error measurements) and calculated parameters for MRP systems.

Our References for This Article

If you want to see our references for this article and related Brightwork articles, see this link.

The software addresses two basic problems.

1. Forecast accuracy measurements are often not performed in companies to enable the company to focus on what to improve. The forecast error measurements used usually are too abstract and divorced from the financial impact can end up with the wrong items receiving the emphasis for forecasting improvement.
2. In all the cases that we have seen over decades of working with MRP systems, they have had poorly optimized parameters (things like safety stock, reorder point, and economic order quantity) MRP systems (usually executed within ERP systems) do not have good ways of managing these parameters.

We consider the application developed to be a “Jiffy Lube” for forecasting and supply planning systems, allowing for an external analysis in a flexible tool that can then provide values that help those supply planning and demand planning systems work better.

Because of our SAP background, the Brightwork Explorer was first targeted towards companies that ran SAP ERP or SAP advanced planning tools. But the application is vendor neutral as all systems, regardless of the vendor, use similar inputs that the Brightwork Explorer calculates. At this point, we were relying on CSV file import and export and were considering an interface to a particular application for future development.

We named this application the Brightwork Explorer, and we thought it would be instructive to describe our experience in migrating our application to AWS.

What the application does is less important in this story than how we decided to leverage AWS.

The Development of the Brightwork Explorer

We began the development of the Brightwork Explorer locally. The development occurred over video conferences with the coding performed in real time from interaction with the designer and business process owner. The developer logged into and coded on the designer and business process owner’s computer. With some of the work performed by the developer on his computer. After the application was ready to be shared with users, the development was migrated to AWS. We chose PostgreSQL as our database and S3 to store upload files. We also started with a small server configuration to begin. We would be breaking the application with a small number of customers and even beginning with smaller test files.

Important Benefits from Using AWS for Our Application

There were a few critical business models that we decided to follow was to offer a cloud application.

This had three essential benefits.

1. Lower Barrier to Implementation: We would never have to worry about getting a customer to implement our software on their server. They would not have to buy the software but could first test it to see if it fit their needs. This allowed us to make the software available to far more customers.
2. Upgradeability and Reduced Maintenance Overhead: We planned to make many upgrades to the software, particularly in the first year. We would never have to worry about previous versions of our software “floating around” eating up maintenance efforts, and we could make our changes directly to our multi-tenant application.
3. Accessibility: We could directly access any client’s data so that we could provide support. This significantly reduced our overhead. This was also true for companies that used the software. The Brightwork Explorer creates simulation versions, and those simulation versions can be shared among various users within one company.

Each time a combination of settings is saved in the Brightwork Explorer, it is saved as a simulation. This is a combination of settings resulting in an aggregate number of values for inventory, costs, profits, pallet spot consumption, and several other critical items. The application allows simulations to be saved so others can review them.

After we decided on the cloud, AWS was the natural choice for us. This is the configuration we leveraged for the Brightwork Explorer. Those were the primary reasons for moving the Brightwork Explorer to AWS. However, for our purposes, we could have also used Google. Still, our developer for the Brightwork Explorer was more familiar with AWS, having used AWS for several past applications.

How Did the Brightwork Explorer on AWS Work in Practice?

All of these beginning reasons turned out to be true. Once we deployed the application, we received extra benefits that we did not list above.

Easy Collaboration With Our Developer

We are not in the same country as our developer, so AWS became a shared space for us to collaborate.

• As our application, we controlled our AWS account and paid the AWS billing but provided our developer with an account.
• If we needed another developer to add something, we could create a new account to allow them access.
• We had several types of collaboration. One was the collaboration with our customers. This was feedback provided by using the Brightwork Explorer application.
• From this feedback, we determined what changes we need to be made.
• We tested a new application and “guinea pigging” our first customers (and telling them this and not charging them for accessing the application in its early state).

One of the areas of change that we needed was the ability to delete simulations. We told the developer to make this change at 12:00 PM, and the change was applied, along with a second change related to date management at 2:02 PM. The changes had been made. We refreshed the screen, and we were able to access the changes. There was no downtime.

Scalability

The second area of benefit of using AWS was scalability. We were going to be initially testing the software with just a few companies. Therefore, there was little need to pay very much for a higher performance and volume system on AWS because of the limited use.

• So we kept our costs low in the beginning.
• We will be able to scale the Brightwork Explorer to any size as new customers come on board.
• This also allowed us to test the response from the market with minimal financial investment.

Conclusion on This AWS Case Study Experience

We were quite pleased with our experience in setting up our application on AWS or Google Cloud from multiple dimensions.

• Previously the Brightwork Explorer had been in a series of R and Python scripts that we ran on projects. And without a reasonably easy way to deliver the business logic through AWS or Google Cloud, we most likely would have never developed the application.
• The effort involved in maintaining such an application would have been overwhelming, and the Brightwork Explorer is only one of the things we work on, so we could not having it consume that much of our time. If we had to distribute on-premises versions of the Brightwork Explorer, we would have lost interest in investing in the application and commercializing it for broader distribution that we think is an essential calculation for forecasting and supply planning systems.

Overall, we are quite pleased with our AWS experience. It is a small application and certainly not an example of anything that leveraged advanced features of AWS. Still, it allows us to get our requirements met quickly and to begin deploying anywhere. While reviewing an AWS document on migration, we found the following quotations.

“Democratize advanced technologies: Technologies that are difficult to implement can become easier to consume by pushing that knowledge and complexity into the cloud vendor’s domain. Rather than having your IT team learn how to host and run a new technology, they can simply consume it as a service. For example, NoSQL databases, media transcoding, and machine learning are all technologies
that require expertise that is not evenly dispersed across the technical community. In the cloud, these technologies become services that your team can consume while focusing on product development rather than resource provisioning and management.

Go global in minutes: Easily deploy your system in multiple Regions around the world with just a few clicks. This allows you to provide lower latency and a better experience for your customers at minimal cost.”

We found both of these proposals to be true of our implementation on AWS.