Working on commercial software and in-house systems, I've seen this happen. Some customers know what they want, and desire to own the configuration, while others just expect the system to magically solve their specific problems and get frustrated with the vendor when it does not. At my current company, we always know we are in trouble with the latter group. They often purchased without doing enough shopping such that they don't know that the competitors have similar limitations to our product. Also, this latter group of customer generally have not thought through what their real needs are--if they don't have a process defined that works for them manually or in another system, no new tool is going to help.
Our best customers have a "system owner" (business analyst) that knows enough to tell us what they need, and if that "system owner" was part of the decision making group when they purchased, we have an easier time. But, in a few cases, where the "system owner" is not experienced or strong enough, we've actually had to go to the senior manager of the customers and help them see that the problem was the "system owner" not the system, itself. In a few cases, we see the customer's management realize the problem is on their side and replace that "system owner" on their own--but most customers just blame us if things go South. When our current product was newer in the market, it was rough, as we could not easily explain that the problem must be on the customer side, as we could not say "well, company X in your same vertical market is using our product successfully, so maybe we just need to look at how you have deployed it.", By for the most part, most of our customers have their act together and have a strong, capable business owner.
Meanwhile, just like the parents that buy the puppy must expect to do most of the day-to-day care, at least at first, so it goes with IT or a vendor. In both cases, a support team that is properly trained and equipped needs to be available to help the customer, while protecting the developers from some of the mundane system configuration issues that inevitably arise.
On the subject of Extensibility
Extensibility is one of those words that means different things to do different people. It seems important to distinguish between the following three terms that are often used interchangeably: configuration, customization, and extension. All three of these options mean more flexibility in the system that is delivered, but each in its own way.
Configuration is a matter of initial setup and on going maintenance of various options designed in to the product. This is generally done through the UI these days, but may still involve editing configuration files. Some of this configuration may extend the product in minor ways, like adding new choices to a dropdown field. Products should require as little configuration as possible. Developers should avoid adding to many configuration options, and instead try to figure out what the majority of users want in terms of configuration and wire the product in that way.
Customization involves one-off modification of the core definition of the product. For example, if the product is coded in a a scripting language, the original scripts would be tailored to meet the customers needs. Customization implies such one-off tailoring that will require manual merging of changes to the original source during an upgrade. Customization should be avoided, as it is generally very difficult to merge changes back into the next release version of the code.
Extension is a vague term. Generally it refers to adding additional functionality in one way or another.
It often implies adding functionality by way of code "plugged in", leveraging hooks and interfaces the developers created for just that purpose. Through extension, entirely new user capabilities are added, for example, a internet browser may be extended to support JavaScript debugging inside the browser in a way that the developers never conceived up.
In a system architected for adaptability, the system can typically be extended through configuration. For example, fields can be added to the object model, range validators can be adjusted, or if fully adaptable, whole new processes or modules can be defined (often through an integrated workflow editor).
Users of course would prefer none of the above (no configuration, no customization, and no extension)--the product should just do it all magically 'out of the box'. Meanwhile, developers should do what they can to avoid falling back to these as options, at least where core expectations are concerned.
Where configuration is necessary, it should be done through the UI and be as easy as possible--as soon as configuration is necessary, a user is doing something they'd prefer not to have to do, so you need to go the extra mile in making this easy.
As said, customization is no way to go at all, but is sometimes necessary for pragmatic reasons.
I will write a separate blog post on other advantages to architecting for extensibility (adaptive architecture) as part of preparing for the Saturn conference and link to it from here. My current thinking is that extensibility has far more value in commercial software than in-house software, but would still be very situational.
In the end, too many choices, too many options, too much flexibility can just overwhelm the average user. Sometimes it is best to fall back to Henry Ford's approach of offering any color they want, as long as it is black. But maybe in cases where users demonstrate they are capable of taking on more responsibility in return for more power, building in adaptability can permit the users to self serve and not wait for turn around time it takes for a new release--or go in the dreaded direction of customization.
No comments:
Post a Comment