Monthly Archives: September 2006

Before we look at IT as a whole, let’s take a look at a more obvious example.  It’s pretty easy to define the job of a programmer.  They take a set of requirements and write code that meets the requirements.  It’s also easy to make that case that programmers can be used to generate value… and they run for days on twinkies alone.  Yet, no matter the skills of the programmers, the value of programming is in what it automates for those using the software.  It’s not enough to simply give a user a number of tools, the tools must be logically presented for the task at hand, and they have to have the *appropriate* level of automation.

The “appropriate level of automation” is key.  Allow me to oversimplify.  It requires a certain number of actions to make text bold in a typical word processor.  We could reduce the amount of work programmatically by making an assumption – such as automatically bolding a whole paragraph with a click.  That’s quicker, but I no longer have the capability to bold individual words, which is too limiting.  On the other hand, if we had to bold each letter individually, it would be a cumbersome process… one that used to be a reality, not too many years ago.

Intentionally or not, this specific scenario is played for every feature that goes into an application… and for every feature that seems obvious, there are 10 that require a deep understanding of how the end user works, what they are trying to accomplish, what they expect to see, how they’ll screw it up… and you can go on and on.  As far as the programmers are concerned, doing it right or wrong usually takes the same amount of work… but the value of the application literally hinges on knowing what the application is supposed to do, up front.  All users who open an application have a certain task they want to perform, and they will gravitate towards applications that do the “right” job in the “right” way.

“The corporate mindset is that if a computer can boot, run Office and access the internet… well… that’s all they do, right?”

Programming is treated as a commodity in organizations that view the task of automation as a means to an end, as opposed to an integral portion of the business model.  “We are now required to keep records of transactions for X years, we think it would be better to do this with an online database… hey programmers, build on online database to do that.”  These projects are usually successful in their scope, but organizations eventually wind up with a hundred different systems that were all built with the same narrow focus, none of which talk to each other and ultimately create unnecessary inefficiencies or duplication.  These same organizations realize at some point that their business is out of control, so naturally, they come to the conclusion that they need to literally rebuild their whole way of doing business from scratch and take a massive technological leap with an aggressive “ERP” project.  Millions of dollar and several years later, they scratch their heads when they wind up with a solution that is far more reminiscent of the old process, than the process the technology should have allowed.  Large scale ($Millions plus) ERP projects have a massive failure rate.  Failure doesn’t mean the ERP was scrapped, failure may be indicated by being overbudget, overtime, underutilized, ROIs much smaller than anticipated, etc… anything that diverges significantly negatively from the original project goals.

Small programming projects tend to be successful because it’s easy to define the processes the programmers are going to automate, the goal usually being to evolve a process with a more efficient mechanism rather than replace a process with something unknown.  Large ERP projects fail for dozens of reasons…  it’s almost impossible for any large organization to fully document all of their existing processes, much less envision how all of those processes can be improved with automation on the whole, and how those changes will impact everything else.  These are seen as capital projects, requiring every employee, every executive, every business office representative to come together as a collective whole to rebuild the business rules from the ground up with technology no one has any experience with.  These projects fail because they expect the organization to function in an unnatural state, rather than using the organizations strengths to drive the development.  In fact, there’s no better way to show how little an organization knows about its own business than to mention the letters “ERP”.

Having to undergo a *large* ($Millions plus) ERP project means, quite literally, that the company has seriously missed the boat on technology – probably for decades.  However, ERP implementations are both inexpensive and successful when it is simply next logical step of an existing, successful, cohesive business development platform.  Surprise surprise, companies that have a successful history of using IT to automate their business processes are more successful in large scale process automation projects.  Duh! 

The ERP debacle, and the fact that so many organizations expect a different result from the same plan, is a symptom of a much larger dysfunction.  If we fail to get value from a cash cow like programming resources, how in the world do we get value out of less-easy to define IT roles in the enterprise, like the help desk, or the systems group, or the software group… etc?  Simple answer is, we don’t.  The corporate mindset is that if a computer can boot, run Office and access the internet… well… that’s all they do, right?  How do you know your large organization has failed to leverage the most basic benefits an IT department can offer?  They use the word “outsource”… a lot.  

We’ll talk about that next time….

 —  By the way, if you’re enjoying these articles… please let others know about them!  Digg this article, mail it, quote it, del.icio.us it, whatever… just spread the word!  Feel free to drop me a line as well!

It’s the boss’ fault.  There… I said it.  But that’s not important right now.  First, a lesson in macro-economics, innovation and human nature.

Is computing a commodity?

A commodity is a bulk product that has no differentiation among vendors.  Commodities are bought and sold almost exclusively based on price as opposed to quality or other unique values and features.

As I mentioned, it is frequently predicted that “computing” and “IT” in general will progress from an individualized endeavor taken on by many, to a commoditized good available on demand from a service provider… like electricity.  Makes sense, who wouldn’t use Enron if they could?

Electricity was not always the poster child of commoditization it is today.  Many companies produced it themselves; they had Vice President level members of the organization to manage it’s production and delivery, and all of it went the way of the lesser known VP of Healthcare (heh… think about it).  Electricity is clearly a commodity today.  The cost and effort associated with producing it makes it infeasible for most… though it’s not entirely unheard of.  The organization I work for produces energy at a significant savings over buying it from a utility, for example.  But electric is all the same for most, so it doesn’t matter who makes it or how it’s made, as long as it’s cheap and always on.  You know what you’re buying and you know what you’re paying.

“the goal of active technological innovation is to simplify, add or improve capability, and create independence”

But is that what people want?  Do you *want* to be tied to a utility for electric?  Let’s look at the phone company over the last decade.  What we’ve found is that people don’t want to be at the end of a leash, hence the cell phone, and people don’t want to be tied to a phone company, hence telephone number portability, the attack on carrier contract practices, and at the ultimate, non-carrier-specific VOIP – all the function of phone service, without the phone company… sorta.  Telephone service has all but lost commodity status, all because of innovative new ways to do the old thing.  It’s happening fast, too, despite every effort of the industry to push against the tide.  Would the baby bells really have survived this long without the rampant corporate protectionism in congressional and regulatory bodies?

The next few years should be interesting.  The cable company will provide data, phone, TV… and so will the phone company.  The electric company is getting in on that action too, finally defiling our virgin electrical outlets with your choice of smut, Ok Go videos and cold calls from your local newspaper.  But the forthcoming wireless technologies put into question whether “tethered” information services will be able to survive at all.  You may get your information from a local ISP over WiMax.  And here’s the very real possibility – a completely non-corporate, community-based wireless mesh.  You buy a box, that box talks to as many other boxes it can find, wirelessly, and we all become one seamless, unowned service provider.  Unlimited data for all, anytime, all the time, with limitless redundancy.

I hold out little hope for that last option.  I think it will be regulated out of existence or lost in the standards committees or fail miserably in proprietary-ville.  The technology to do it exists today, and several companys could make a mint off of supplying the gear, but too many existing companies will feel they need to be protected from such a democratization of service, and there’s no shortage of lawmakers willing to comply, quid pro quo.

So, back to electricity.  If electricity was able to be produced in large quantities easily, safely, cheaply, and reliably, even redundantly… using a device that fits in with your air conditioner and water heater… would you use an electric company?  Of course not, people don’t *desire* utility service, they simply endure it as a matter of cost (including time, risk, reliability, etc). 

I say all this to illustrate a simple truth.  In practice, the goal of active technological innovation is to simplify, add or improve capability, and create independence – “Hey, look what *you* can do now.” 

It takes no great leap of wisdom to say that something, sometime down the road, might become a commodity.  Everything has that potential.  All it requires is that a something is either so unwieldy that it can’t be done/produced independently, or so stagnant and common that there is no way to get an advantage through independence – “Hey, we’ll do that for you faster/cheaper/better than you can do it yourself.”.

It’s that second part that forms the basis of the outsourcing debate.  There is a corporate belief that IT is stagnant.  There is a belief that there is no differentiation between IT services…. and that for a specific amount of money, you get a specific amount of service.  Is that true?  Or has IT has simply been so misaligned with business, its strengths so under-utilized, its impact so poorly measured, that no one has a $*%(#_@ clue if the power is on?

So is computing, and therefore IT, a commodity?  Does treating it as such have merit?  We’ll find out in the next article… and I’ll blame the boss – again.