Request your demo of the Sigrid® | Software Assurance Platform:
We have all seen it before. The implementation of ‘the holy grail’ a brand new ERP, CRM, or WMS domain (choose your preferred software package abbreviation) promising to streamline your processes like never before, out-of-the-box! Merely configure what you need! Right? More commonly than not, we see implementations rife with custom coding that, in some cases, even dwarfs the size of the software package itself.
Our Sigrid® | Software Assurance platform inspects, measures, and monitors these types of environments and we see the same story played out time and time again. What convinces us that we are immune to warnings from known ERP literature of the 1990s about failed IT projects that do not apply to us? The default implementation will not work for us because our company does something nobody else does and works differently. Why do we all want something bespoke?
Maybe this behavior is ingrained in our human nature. I got to experience it up close again during our annual family weekend to help my parents set up their glamping experience on one of the Dutch islands. The moment you put a raised two-person mattress bed and a tabletop fridge in a tent, it is camping no more. So… Glamping.
While hard at work setting up the tent with the sun to our backs, we have time to browse the other tents. At first, they seem to be merely different in size however, slowly you see the myriad of customizations in terms of window placement, aircover sizing, type of bindings, canopy setup, etc. The same goes for my parents every year. My dad opens up the bag with heavy metal support rods and concludes that last season’s color-coding will not do! Henceforth, we spend the following hour sifting support rods to reverse engineer where the heck these should be placed. Sounds like a familiar type of situation? As a developer, you probably recognize this, even when looking at your own code from a year back.
When it comes to software, this is apparently no different. Whether from an Architecture Quality point of view regarding the application construction or from a secure coding review: changes to the standard come attached with risks and inevitably cost time and money. Is it really worth the change? And after making the change: will this change be easy to understand in the future by other people?
My experience is that most of the standard suffices for 95% of what people need. It is not the standard for nothing. And although it is hard, you need to have your priorities straight and be ready to act upon them:
More often than not, I run into situations where people think they are special… which is true, for a niche part of their work. For all the rest, leave the bespoke stuff to those that really need it. If you can live with the standard for everything except that unique, differentiated process then you are already ahead of the game. Make sure your customizations count and do not let them be your short-term solution and your long-term limitation.
Author:
CTO
We'll keep you posted on the latest news, events, and publications.
