This insightful article from Thomas Wailgum at CIO.com summarizes the typical situation organizations face when having to adapt commodity software to a changing business and to their specific processes.
Do not change ERPs
Traditional software packages (ERP suites the best example) are, by definition, not meant to be customized. The strategy of ERP vendors is to embed in their software, business processes that are common enough to be deployed in the largest possible number of companies. The continuous addition of new functionality produces a bloated mass of alternative code with very complex product release cycles.
Organizations that customize a package create a private “code branch” that needs to be maintained in-house. This is like diving into the gates of hell. From that point on, you inherit part of the vendor’s complex development cycle. You make it very difficult to merge your own changes with the next product release of the vendor. Your maintenance cost sky rockets and your meager resources get sucked by these packages. The wise and experienced IT professional only needs to go through this process once to never again dare to customize an ERP.
But if you use packages to only implement commodity processes how do you support the processes that are your own? And how do you support processes that are the result of internal innovation and represent your own strategic competitive differentiation?
Commodity vs. Competitive
To hint on the answer, I will borrow Geoffrey Moore’s Core-Context model. Geoffrey categorizes processes and their respective IT according to two vectors. On one axis, Core vs. Context. Core processes are the ones that are your source of differentiation. Context processes are all the others. On an orthogonal axis he classifies processes as non-mission critical vs.mission critical. The end result is a simple chart that depicts 4 stages of evolution of these processes.
<core vs context.png>
Innovative processes, strategies and ideas and their supporting IT, flow from the Invent, up to Deploy To Scale. In time they become a commodity (as they are copied by others) and move sideways to Manage Scale. Finally some of these processes stop being mission critical and can be Offloaded.
Packages are a good fit if applied to processes in the Context quadrants. And, in this case it is acceptable that the organization actually adapts to the ERP processes. Hey, it is commodity, so except for some reengineering discomfort, why not?
<core vs context with package.png>
Build Custom Software
IT applied to the Core quadrants however, needs to reflect the innovation that is created inside the organization. In this case you need to build custom software. You need to have the software adapt to the organization processes. There is really no way around it.
ITs that support fast changing organizations, are already doing this. A typical enterprise architecture tends to divide itself between packages and custom built systems. A zoo of Java and/or .Net systems, Sharepoint customized portals, and Process Workflow tools support the two left quadrants. Web Services (I don’t dare use the term “SOA”) glue these things together.
So, is this a good strategy? Isn’t there anything to hate about custom systems? Yes, there is. I will blog about it later.