What is the “systems flexibility curve”? As an enterprise architect, I am frequently asked to help business leaders decide on which solutions and approaches to use to fulfill a business need. These decisions are often the inflection point [investment wise] of millions of dollars over many years and in some cases can be of a very high level of criticality to the business. The “systems flexibility curve” is a visual representation of the trade-offs uncovered when determining the best way to fulfill a business need with a solution. The chart represents several competing interests. When we look at the various factors involved with using technology to fill a business need there are competing factors. This graph was created out of a need to help mostly non-technical people [business leaders] understand some of the factors going into a build vs. buy and or new solution discussion. I will try and define them for the reader here:
At the far left of the graph we see a system that is custom-built to the exact specification of a business process where the customer [business partner or client] has complete flexibility. A solution in this space requires significant long-term investment in maintaining the custom built solution and thus the high labor costs and associated risks. The final attribute of a solution to the far left is the slow speed of delivering the solution.
A solution at the far right of the graph is one that was purchased and deployed out-of-the-box with little configuration. Thus we see the automation is high with regard to the business process. The high systems cost is representing the purchase of the software or solution and the high one-time, upfront costs. The speed of implementation is very high.
The truth is that most solutions that get deployed into production are typically somewhere or on some scale in the middle, it is pretty unlikely that a solution would be on one of the extreme ends of the spectrum.
In conclusion, this graph or visual representation of the systems flexibility spectrum has been very helpful to me over the years and I encourage others to use it as well. There are assumptions made with the graph and these rules are mostly true. There are some outliers that make these assumptions untrue. There are ways to get the worst of both ends of the spectrum. The most common is the typical ERP trap where an organization purchases a software package and customizes it to the point where it is no longer maintainable by the vendor. This is literally the worst of both worlds where you pay for the customization and the high maintenance costs. This is broadly considered to be an anti-pattern in the industry. Enjoy!