coneblog

I continue to see organizations choose to do a major custom development when viable alternatives are available in the marketplace. The reason given is usually that “our requirements are unique”. The real reason, especially in large organizations, is very different.

Often it is some version of empire-building: Control of budget, staff, and resources. A big custom effort has a long life-span, and will soak up resources far into the future. And like President Bush’s war, once you get into it, you can’t easily quit.

A secondary reason can be “Architectural Elitism”, a situation in which the emerging architectures of the future are strongly favored over the proven architectures currently found in the marketplace.

With the current focus on re-architecting everything in the “Web Services” direction, there is a new crop of “Architectural Elitism” springing up. This leads to situations in which a modestly-sized operational support group in a global organization embarks on a $20 million dollar custom development project instead of buying and modifying a proven package solution.

Why? The packages available didn’t use the latest web-services architecture. The funny thing is that the support group would not consider buying a current Vendor offering featuring a services architecture, as it would be “unproven” and “risky”. But they will leap off into a highly risky big-money custom development project.

Not one in ten organizations has the skills and culture to pull off a major custom development project. It isn’t about resources. In fact, a surfeit of resources is often a contributing factor to the projects failure. We have all seen the projects that have sunk under the weight of dozens of staff members or consultants.

I was in the business of custom systems development for many years, and for most organizations, building your own is a last resort. But, coders got to code…