Systems Flexibility Curve

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:

• Automation: – This is describing the level of process automation and configuration that comes out-of-the-box.  This means that your business processes are integrated and highly automated.  Some examples include typical vertical solutions such as mortgage origination, work-order fulfillment and  accounting software suites.  In these scenarios, the business processesare a commodity and common.  In a scenario with a need for high automation, you are typically purchasing the business process and the software.
• Flexibility: – this factor describes the level of flexibility beyond typical configuration.  High flexibility is sometimes warranted where there specific business needs that require a high degree of customization.  High flexibility is almost always associated with custom software development, where solutions are created from the ground up.  In product development there is almost always a high need when compared to traditional industry vertical scenarios.
• Implementation Speed: – this factor is trying to describe the speed at which a solution can be delivered.  From concept or need identification to roll-out in production.  This includes configuration and testing or development, testing and deployment.
• Manual Intervention: – in this case we are describing the need for ongoing intervention or maintenance on the solution itself over time.  In a custom developed solution, the solution will almost always require bug-fixes, process change work in the solution as the business processes evolve over time.  In buy scenarios, these activities take place, but the originating vendor bears the cost, not the purchasing organization.

With those descriptions established, lets talk about what the chart means in it’s totality and how it can help you in your enterprise architecture activities.
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!