Wednesday, April 29, 2009

Why Standards don’t (read: shouldn’t) Matter in Corporate IT

As my first blog post I wanted to write something somewhat controversial. I suppose the title isn’t all that inflammatory because I decided to soften it a bit. Originally, it was “Why Standards Don’t Matter” but since having a number of conversations I feel I should soften my stance. A bit.

So, what do I mean by this? Well, to answer that, you need to understand my perspective. I am in a technical pre-sales role where I get up in front of (largely) technical audiences and try to sell them software solutions. Sometimes this is easy and the crowd “gets” it, but other times the crowd comes to the meeting with an agenda all of their own (e.g. to make the presenter look like a fool). In the latter case, one of the most common objections to any software solution is, “what standards to you support” or more specifically, “how does your tool support standard X?” Luckily for me, I work for a company that prides itself on support of Open Standards so my answer is usually along the lines of “we support version x.x of that standard and plan to support enhancements as part of our go-forward product strategy.”

It hasn’t always been this easy for me though. At my past company, where I was primarily selling Business Process Management tools, the standards debate was one that would come up time and again and threaten to slow the sales process to a crawl. Often times it would cause hour-long tangential conversations that were often times unnecessary. My favorite way of dealing with this objection (with the IT crowd) was to ask them why does adherence to the standard matter? Often times the response would be about their desire not to be “locked in” to the vendor with a proprietary solution. On the surface, this argument sounds reasonable. However, this begs the question, “how often do you expect to switch enterprise software vendors for your key Business Process Implementations?” My guess is, that if polled, the Fortune 1000 would answer this question with a resounding NEVER! This is because the associated risk with moving a core application from one platform to another is so risky, so timely, and so expensive that no one would ever attempt it. Furthermore, most enterprise application implementations are expected to last at a minimum of 3-5 years. After that much time has passed, the standard that was so cherished by the organization has moved on, significantly, and thus the implementation team is forced to either rewrite large portions of the application or start over from scratch with the latest version of the standard.

So, I ask again, why do standards matter? Well, to corporate IT developers they really shouldn’t. They are a silly objection that holds little bearing on the overall success or longevity of an IT implementation. However, from a global perspective I am all for them. I mean, what would happen if we had more than one unit of measure for things like, distance, temperature, enterprise portlet development, or business process definition? Oh wait…

3 comments:

  1. Maybe the question should be, "When do standards matter?" In the early phase, before crossing the chasm as Geoffery Moore says standards can get in the way. Later on as technology matures standards are critical. I would hate to see the railroad today with no track standard (http://www.truthorfiction.com/rumors/r/railwidth.htm)

    ReplyDelete
  2. To use your analogy about railroads, aren't there different gauges of track (narrow, etc)? I think that trying to nail everyone down to one standard is foolish, yet people love to argue over which standard is best. I guess my point is that organizations should try to adhere to standards where it makes sense, but go their own way when they feel they can do better. This isn't religion, yet folks like to treat it as such.

    ReplyDelete
  3. I agree that it is rare to migrate an enterprise solution from one standards implementation to another (JEE, DB, etc).

    But I think it is more common for the developers to use one implementation for one project, and then another implementation for the next project. If I've developed a JEE app on WebSphere, I probably can get up and running on JBoss or WebLogic much quicker than learning something totally new. Skills portability is a factor to consider.

    ReplyDelete