In gardening, a hedge is a line of shrubs which forms a barrier between two areas. In finance, a hedge is a risk management strategy based on making investments or business plans in such a way that a loss in one area of the portfolio will be balanced by a gain in another area of the portfolio. For example, Southwest Airlines correctly predicted, a few years ago, that the price of jet fuel was going to rise dramatically. Normally, this would hurt their business. However, they used this prediction to lock in long-term contracts at a rate which may have seemed high when they were signed, but which quickly turned into a bargain when other airlines had to pay twice as much for their fuel. Hence, the rising cost of jet fuel became a business advantage for Southwest, rather than a liability.
Last night, the Columbus Architecture Group met to discuss the effects of the economic recession on software vendors, IT departments, and other projects. One area of discussion which I found particularly interesting was the notion of how to build hedges into enterprise or software architecture. In other words, can we examine areas of business risk, and design teams and systems in such a way that they, at least partially, offset this risk?
I’m writing this post more as a question than as a statement of advice, but I will give some examples here in order to clarify what I am asking.
- Last year, my company recognized a need to be in a certain area of the market which we had not previously served. But exactly how to enter this area of the market would depend upon sales needs which were not yet clear. There were two routes we could take, both of which had significant advantages. Taking Fred Brooks’s dictum of "Plan to throw one away; you will anyway" to heart, we started working on both projects, with full knowledge that we would be unlikely to complete both. As anticipated, one of the two projects was eventually left behind. But the other one was better for having undertaken it, and we had mitigated the risk of choosing incorrectly.
- Another participant noted that he had a programmer working on a project which would eventually require to write code to accomplish a certain task. He noticed that another team was working on a similar functional area, although they were not close to completing this work. He asked the first programmer to put off work in this area for another month, which she could easily do, due to the amount of work required in other parts of the project. At the end of the month, they would assess whether the second team had completed enough work to make integration of that team’s code a better idea than writing new code. As it happened, the second team’s project was not far enough along to help the first programmer. However, the cost of rearranging her schedule had been very low, so even though it didn’t provide any actual benefits in the long run, it was still, in hindsight, worth doing.
- Economic conditions which are destructive to one area of a market can be beneficial to another. For example, as companies consolidate due to shrinking markets, there may be an increasing need for software systems integration.
Now I’d like to turn the question over to you: How should architects and developers build hedges into our products and process?
Here’s one response from Jody Dawkins. If you’ve tried to comment in the past couple of days, please forgive the overly aggressive spam filter on this server; it should be fixed now.
Post a Comment