If you build a better mousetrap, the world will beat a path to your door... or so the saying goes. I think this is part of the reason open source projects sometimes enthusiastically announce that their new version is a complete re-write of the code. They're building a better version of their own mousetrap. Do people beat a path to their door?
Well, to continue the metaphor, only the people who have some mice to deal with are interested in mousetraps. These days, there is an open source project for pretty much every issue and challenge you can face in IT. Some are still pretty far from their commercial competitors. But others are market leaders.
This embarrassment of riches is great from a marketing and evangelizing point of view, but it doesn't automatically translate into IT success. At the technical level, open source is simply a development methodology for software. It is not a panacea. The fact that you have a dozen database platforms to choose from does not mean you're going to have a terrific database in the IT system you're building, or that you know how to implement the one you need, in the right way.
So one moral of the story is that you need to know your mice, and understand your traps, in order to deal with this situation. But there's more to it than that. As another old saying goes, when all you have is a hammer, everything looks like a nail. We've done enough cleanup projects, after the initial developers have left the building, to know that technical expertise is not enough to guarantee success. Designing successful IT systems requires a particular set of skills, what the business world has long described as the "Business Analyst" role.
In the open source world, everything is supposedly a meritocracy where the best ideas rise to the top. Consequently, there are a lot of technically capable people in the open source world, focused on using and improving the technology. But it's equally important to integrate this technical knowledge with the real-world needs that organizations have. When a project lacks this ephemeral ingredient, there is a risk of failure.
At Freeform Solutions, we have learned this in a few different ways, including "the hard way." We now require all projects to go through an agile project management process, which de-emphasizes the technical parts of the work and focuses on the needs of the users and the organization. We use "user stories" as the base unit for organizing requirements and our work. We have found this to be a very flexible approach and one that clients can engage in regardless of their own technical knowledge, since the stories are all about the users and what they need, rather than how we're going to reconfigure the flux capacitor.
I think there's a natural affinity between open source methods and agile methods. This may sound strange, since agile methods owe their existence in part to a lot of big companies, including the automotive industry, which is not known as a bastion of open thinking. But I see a kinship in the focus on value. Open source solutions are ultimately driven by a desire to solve a problem, to meet some specific need. They're not fueled by marketing agendas or business deadlines. Agile processes focus on delivering value as the only measurement of success. It doesn't matter if the database is 90% configured, what matters is whether the user can do what they need to do.
We believe open source software is an essential part of a flexible and effective IT strategy. But we also believe there's more to effective IT than the technology. It's also important to focus on the value, from the user's point of view. It's the difference between building a better mousetrap and recognizing the right time and place to use it most efficiently.
Recommended Reading:
Posts
No comments:
Post a Comment