Software Solutions, The Hard Way

Software product developers are often thoughtless (ok clueless) about how their solutions are deployed, maintained and used. That's why we have Microsoft Word and J2EE.

But this isn't about that.


Literally, the term "I.T." implies involvement and mastery of the entire computer science / information science domain. In practice, I.T. usually involves operational aspects of software solutions including the solutions themselves as well as storage, network, support, security and compliance.

I.T. organizations that are asked to develop software solutions are often managed by people who are inexperienced in product design and totally focused on operational stability and risk reduction (as they should be).

That's why you get over-budget, unfinished, eternally "enhanced" expensive systems that are very secure and often highly dysfunctional. Those systems run along side non-secure and impossible to support "stovepiped" VB and Excel solutions and "legacy platforms" that are so covered in band-aids that no one remembers what they looked like. The monsters can never be killed because they plug the functional gaps in the "real" systems.

So you end up with the least cost effective solutions on the books and the least secure, most difficult to integrate solutions on the desktops.

No amount of process will solve this problem (ok that's my opinion). ITIL, which has been very very good for ITIL consultants, authors and internal governance groups, may or may not be great for improving operational performance. But solution development?

If I.T. departments were hotbeds of innovation and magnets for the best product developers, perhaps a bit of process could tweak the bottom line. But that's not the case. The problem is not lack of process.  It's lack of experience, vision and skills (for product managers even more than for developers). In most cases, I.T. organizations, because of their responsibility to focus on running long term  cost effective programs to ensure operational stability and minimize risk,  present the very opposite of the environment in which innovation is possible.  Not just technical innovation, but innovation in the processes behind software product development.  That translates into lowered expectations and solutions that are delivered at the highest cost, with the longest development cycle and the lowest probability of  customer acceptance. Extensibility? Interoperability? That's a whole other post.

Even Google, as it has grown, has had to deal with this reality. Your organization delivers product as well as Google does? You can stop reading here.

If you're a business manager with a problem that needs a technical solution, you can spend a lot of money and time trying to teach your I.T. organization to cook by having them read books about dish washing. Or you can go out and hire a few guys (and or gals) in a garage. Your choice.

You can even buy the garage. But, unless you enjoy watching flowers wilt, I wouldn't recommend that.

Added 1-18:
Here's a now well known example:  http://science.house.gov/Press/PRArticle.aspx?NewsID=2289
It seems as though 1/2 billion dollars and 800 contractors just wasn't enough. A more detailed account (PDF) can be found here: http://democrats.science.house.gov/Media/File/Commdocs/Staff_Memo_toBM_terror_watch_8.21.08.pdf