20,000,000 gold pieces for Gloves of Modification

posted by Heath Buckmaster on May 08, 2007

I am a big fan of the role-playing game, Neverwinter Nights*. I can pretend to be a wizard, a rogue, a fighter, or even a paladin, and save the kingdom from evil with my trusty +1 Vorpal sword. The game is simple to install: I just take the CD’s out of the box, run the automated installation program, enter my license key and I am in the game. “Off the Shelf”…”Out of the Box”…The company has written the code and the storyline that is needed to create my game experience.

But what if I want to change the way the game plays? I might want the screen colours to be brighter, or the level of difficulty to be easier. I can do all of that by configuring settings in the options screens. The software already comes with the ability for me to make those types of simple changes to the way I use it and the way I want to play it. But what if I want my basic +1 Vorpal sword to inflict magical fire-damage instead of what it normally does?

Sorry, that can’t be changed with a configuration option because it’s a basic part of the code. A +1 Vorpal sword behaves in one specific way. If you want to change that, you’ve got to go buy or find a different Vorpal sword! Changing the program code would alter the function of the software and how it reacts to that weapon, so it is not even an option for me. I have to take what the company gives me and live within those boundaries, potentially changing the way that I play the game (I find a blacksmith who can hopefully sell me a better sword).

For those of you who are not gamers, let’s move to something more prevalent - using commercially available desktop software to read your email (vs. a web based tool). In most software you can change the fonts, the colours, the rules for how email is filtered, and you can even change the panes of the screen if you prefer reading an email on the left or the right side. But what if you wanted your software to store email in a database instead of the proprietary data file that it creates? Sorry, that can’t be changed because that’s a basic part of the code. Changing that would completely alter the function of the software, so it’s not even an option for you. You take what the company gives you, and live within those configurable boundaries (so I make space on my hard drive for a huge data file since I can’t use a database).

But what happens when you step up to enterprise software. Millions of functions, thousands of screens, portals, user exits, system calls, extractions, it’s enough to make your mind overheat. Of those millions of functions there are hundreds that you will actually use. Some of those are useful right away (off-the-shelf) because the vendor has pre-written them based on the way your type of company generally does business. For example: a car company builds inventory, stores it on their lot, books an order when a customer chooses to purchase a vehicle, then they watch you drive the car off the lot (shipping). It’s a pretty basic sales process.

You might, however, want to tweak and configure some settings because your company does something a bit fancier. Maybe you build inventory, store it, book the order, then sell it to someone who then sells it to someone else. Now there’s an additional element you need to track related to the “reseller”. So you go into the software, check those flags or click those buttons, and with a little configuration of provided options you’re tracking those additional items.

But what if your business process is even more specialized? What if you want to book an order before you even build the product? It’s an excellent way to build a better sales forecast, minimize inventory storage requirements, and minimize product spoilage, but now you have to accommodate orders changing before the product is built or shipped. That functionality does not come with the base software offering. Why? Because this is a unique way of doing business. Yes there may be tactical advantages to it, but it’s not standard.

Now you’ve traveled beyond the realm of configuration into code modification. And believe me, this is very dangerous territory unless you’ve upgraded to a +5 Vorpal Sword with Gloves of Modification. That’s right…you need to buy new gloves if you’re going to change the code. The first and foremost risk item is that if the software is not designed to work the way you want it to work, you’ve got to change it and hope that you don’t break something. Service packs and version upgrades don’t know about your modifications, so who knows if they will overwrite them or even fail to install because of what you have done? And that’s only the beginning of your problems.

Once you get into the habit of changing code to fit your unique demands, where does it end? I can tell you that 13,000 customizations later, it ends with you being multiple software versions behind and having to build a brand new infrastructure to support your business because you can’t upgrade what you’ve got. Talk about a problem. So how do you make these decisions?

It sounds too easy, but at the root of the matter you have to determine if there are unique elements of your business process that give you a competitive advantage in the industry. If there are, then maybe a modification is the right way to go even though there are risks. If the Return On Investment (ROI) is sufficient, you might be willing to re-code the system after every patch or an upgrade, and keep going on your merry way.

But you must always ask yourself (and your business customers who are requesting it), “Do I really need this unique process for some competitive advantage? Is there another way of accomplishing my business flow that gets me to the same result but uses a more standard approach? Have I checked the right options and set the right flags to get me close enough to compromise? Could the business process make a change that would solve this problem? Could I hire a wizard to help me win the battle so I don’t have to spend time finding a better sword?” Without a rigorous review process that can seriously and realistically look at any modification requests and determine whether or not the business or the software has to change, you’re at risk for disaster.

If you choose to change the business, you’ve got a significant Transition/Change Management (TCM) task ahead of you. If you choose software modification, you’ve got a significant long-term support risk ahead of you. My initial vote is for changing the business, because even though TCM takes time (and often a culture change), you’ve only got to do it once, not every 3 months when a new service pack is released. But is that realistic?

In part 2 of this article we’ll look at Balancing “Off The Shelf” and your Business Needs.

* Neverwinter Nights is a trademark of Wizards of the Coast, Inc. Other product names and titles mentioned in this article are the property of their respective owners.

Comments (1) (closed)

tagged: coding, customization, enterprise software, gaming, modification, software, TCM