Many supply chain software companies want to sell an entire suite of products to their customers, but oftentimes, only a few of the products fit a customer’s needs.

At Bastian Software Solutions, we are a custom software shop. That being said, we still chase the dream of architecting our Exacta WES suite to be more of a COTS (Commercial Off-the-Shelf), or, as we like to term it, a one-size-fits-all solution to the incredibly complex logistical problem that is warehouse execution.

The initial development of the Exacta 6 WES included a heavy focus on the development of standardized, one-size-fits-all modules. Why these standardized modules? Well, for one, not having to develop brand new modules for every new customer significantly reduces the amount of manpower required to develop, test, deploy, and subsequently maintain and support those modules; this in turn lowers costs for our customers. In addition, standardized modules allow our team to more quickly assess how a customer's needs will map to our current product offerings.

This, however, leads to another question. What if a customer's needs aren't totally encapsulated under the scope of our standard product offerings? Do we turn them away? The answer can be found in the first sentence of our mission statement:

"Bastian Solutions is dedicated to helping our customers excel in their markets and achieve their strategic business goals by providing the best material handling system solutions, innovative software, and custom automation engineering."

For some companies and industries, strategically turning business away that doesn't completely line up with their standard offering might make sense. As for us, we want to help our customers excel in their own industry, not force them to change what they do best with the intention of fitting them into the scope of our one-size-fits-all software.

Our new way of describing our Exacta 6.x product line, is One-Size-Fits-Most-But-With-A-Little-Customization-Can-Fit-All. OK, so that term is a little ridiculous, and not actually what we go around the office saying. Essentially, this new mantra boils down to an architectural emphasis on developing standardized modules, with a flexibility that allows customizations to occur within the standardized modules at a very granular level.

You should have the option to select the software modules you need most, whether warehouse management system or warehouse execution system functionalities.

What does this mean? Well, as mentioned before, it means lowered costs due to sharing a majority of our codebase across all of our customers. At the same time, if a customer has a very unique requirement that doesn’t totally fit under the umbrella of standard modules, we can satisfy that requirement without a complete duplication or rewrite of the standard module which needs to be customized.

A Hybrid Approach

So how do we achieve this hybrid approach to developing customer solutions?
In the earliest days of supporting customizations, configuration files and database configuration were heavily utilized to facilitate the enabling of specific features. So, if a customer had a new, unique feature, we would add that feature to the standard module and then set up a configuration element which would allow us to toggle that feature on and off. However, as projects went by, the standard module would grow, along with the associated configuration file. This means the cost of maintaining, testing, deploying, and supporting the standard module was also growing, only to support a myriad of unique customizations that most likely will only be used by a handful of customers.

What is our solution then?
For all new modules moving forward, we are utilizing the concept of Dependency Injection (DI) and the Managed Extensibility Framework (MEF) in order to achieve a system which has more emphasis on code-as-configuration over explicit configuration files. This means that our standard modules are designed from the ground up with strategically located extensibility points, and even more so, every piece of code in the standard module can be swapped with a custom chunk of code. If a new customer has a specific requirement that isn't fully satisfied by the standard module, a new codebase will be developed separately from the standard module, just for that customer. Then, when the standard module is deployed, the custom library will be deployed alongside it, providing the hybrid solution that meets the customer’s needs.

A More Relatable Explanation

In order to achieve this level of flexibility in our software, some overhead cost is incurred due to the increased complexity of managing the composition of modules in such a finely grained manner. In order to better understand how our standard software modules are composed, I'll go over an (extremely over-simplified) analogy of composing a car with the same techniques we use to compose our software.

To start with, we have our base ExactaCar. It handles most transportation needs, has two doors, basic tires, manual transmission, and an engine that meets the most basic acceleration and speed requirements. We store all of the parts for the standard ExactaCar in our special warehouse (think of this as a code library) that only contains standard parts and is always guaranteed to have those standard parts.

When the manufacturing facility (consider this the application that is booting up) requests the parts for the car (i.e. doors, tires, transmission, and engine) to be built, a worker is sent out to gather those parts and bring them to the manufacturing facility to combine into the final, running ExactaCar (which represents the final running Exacta module). This worker has very special rules; he/she is told to visit the warehouses for car parts in a very specific order. But wait, there is only one warehouse for car parts? So, the worker goes into our special warehouse, grabs all of the standard parts for the car, takes them to the manufacturing facility, and out comes an operational standard ExactaCar.

Now, let’s say a new customer comes along and wants an automatic transmission car with all-terrain tires. Now, in addition to our special warehouse containing all of the standard parts, a new custom warehouse (think of this as a custom code library) is constructed such that, when the worker is traveling to get parts for a car, he will arrive at this custom warehouse first. This new custom warehouse contains the automatic transmission and all-terrain tire parts.

So, when the manufacturing facility requests the parts for the car (i.e. doors, tires, transmission, and engine), the worker will first arrive at the custom warehouse and pick the automatic transmission and all-terrain parts. After he/she leaves the custom warehouse, the worker checks the transmission and tire parts off of the checklist, but he/she still needs doors and an engine. So, the worker keeps travelling until he/she reaches another warehouse of parts.

Finally, the worker arrives at our standard warehouse and is able to pick the basic two-door and minimal engine to finish off his checklist. When the worker arrives back at the manufacturing facility, he/she drops off the parts, and a short time later, out comes an operational hybrid ExactaCar with 2 doors, all-terrain tires, automatic transmission, and minimal engine--just what the customer ordered.

Conclusion

At Bastian Software Solutions, we understand that as times change, so does the material handling industry, so we are utilizing modular, highly composable design to set ourselves up for easy extensibility and expansion in the future. The reality is this approach to building software does take more effort and diligence but pays for itself in flexibility, maintainability, and testability; and in the long run, will pay for itself with continued customer satisfaction.

If you're looking for supply chain software--whether a warehouse execution system, warehouse control system, or a combination of both--please contact us. Our software team can create the right solution to fit your business needs.

Author: Justin Kaffenberger