My first week has come and gone (officially) in my new role as eBusiness Manager. Not only is this a new role to me but we are also replacing two people on the team who had previously been in development roles for several years at the company. One is advancing to corporate and the other is leaving the organization. One replacement has been hired and his first week was very challenging, to say the least!
The Open Source Dilemma
I’m an enthusiastic supporter of open source applications and development. However, without proper documentation of home-grown applications, the cost savings up front of an open source deployment will eventually come back to haunt you down the road when those original developers leave. This is the exact position we are in. While it won’t be damaging to the organization, it will create a rather steep hill for the new developers to climb as they dive into the custom code (and lack of documentation).
When to buy or build?
This had me thinking during the first week in this new position — where is the line drawn between buying software and building software? I have to bring up a saying I use quite often: “Just because you can, doesn’t mean you should.” I think this is a perfect application for this phrase. I’ve discovered a lot of the home-grown applications were built as a cost-savings measure and “because we could.” That mentality has backed us into a corner today as we scramble to educate the new hires as quickly as possible before the original developers leave the organization.
Don’t view IS as a cost center
In talking with the original developers, it seems as if the mentality of the organization was such that IS was viewed as a cost center, not an innovation center. Therefore, an expenses incurred in IS were viewed as negatively impacting the bottom line. As a result, we ended up with a lot of home-grown applications utilizing different languages and database backends. This strategy works if you never plan to migrate to new technology and never plan to advance your developers.
Future-proof your IS strategy: standardize and document
Moving forward, we will begin to standardize on select platforms. We have a series of consumer websites, internal applications, intranet sites, and reporting spread across a myriad of technologies. Our downfall was this strategy (or lack thereof) which resulted in dedicated employees for managing each of the technologies/platforms. Since each platform was different, development was being handled in silos with very little strategy being shared between the silos. It also made us extremely dependent upon the individuals in charge of the silos.
Standardizing on a few select platforms and technologies will enable the proper cross-training among existing staff to be able to support applications in the event of individual vacation schedules, sick days, or departures from the organization. It makes sense from a technology strategy, business strategy, and also in keeping the sanity of your staff. It’s no fun for the weight of the world to be on the shoulders of a single individual.
Documentation seems to always take a back seat to projects in any business. In an enterprise like ours where we rely on reports and data feeds from external vendors, corporate IS, and other departments, documentation can save a lot of time and also prevent downtime. We have the fortune of being forced to start with a clean slate with new developers, so our first several weeks will simply involve documenting existing applications and systems.
