Ok, so maybe that is overly dramatic. The DIY approach that many companies have taken over the last 5-7 years was largely a vestige of the iron-fist execution of IT shops from the mid 1990’s. As the business units had continued pressures to get work done at an accelerated pace, the rate of change in technology was being constrained by a pervasive belief that only through limiting change could security be implemented and costs be controlled. (Both of those are fallacies, but that is for another Blog post) So there you have the poor business unit who, one day, realized that if not for their funding, the IT team would no longer exist.
BAM! balance of power shifted and enter the Ty Pennington of development!
Now before you pop off with, “Wait a minute Mr. high and mighty software guy! We know our business better than your IT folks and with the tools that are out there, we can do just as good a job if not better than you can!” (Maybe I added the emphasis for dramatic flair.) Well, before we engage too far into this lengthy topic, I want to convey an analogy I used with a client at lunch today. I am engaged to evaluate a solution that was implemented primarily by the business units with some level of assistance from a central service based IT group. Sadly, that system, once live, hit significant performance and scalability issues (two of the main things overlooked when software is built by folks who don’t build software for a living. Now don’t feel bad as those two items are often also overlooked by professional software developers, but that is a separate and distinct malady relating to the dearth of good software development shops out there.) Anywho…
I mentioned that business units writing software was akin to a person standing in the rain. The person has a genuine need to get out of the rain just like business units, often times, have genuine needs for software to be purchased or developed. And while (if it were me in the rain) I may be able to cobble together some rudimentary structure like a lean-to, a home I hath not built. Too often we see a proliferation of lean-tos (That may be an improper plural but roll with me) in the technology and business landscape. Rather than working collaboratively to do some solid evaluation around build versus buy and then, if build is the right answer, some architecture and design through either internal staffing or tactical partnerships, the organizations choose a path of shoot first and aim later.
Prior to your diatribe about how business must operate at a new speed in this economy, remember that quick and dirty tweet from this morning? When you do something quick and dirty, the quick is forgotten long before the dirty (I know that is lifted from someone so if you know who, let me know and I will give credit). Business is always under time pressure (just like I was in my analogy as I stood in the downpour). Sometimes we have to just build a lean-to and weather the storm. But, if we plan to ever get out of the daily grind of half-measure tactics and ascend to a combination of strategic thinking bolstered by tactical execution, we must realize that there is a difference between a ‘cost’ and an ‘investment.’ When we simply go for the rapid fix, we are spending money (cost). That spend is often tough to quantify because rarely will teams own up to the follow-on spending of repair and rework that comes with myopic attack models. When we are mindful and plan our assault on a problem, we are truly investing and can plan to reap all of the associated benefits.
Are you spending or investing?