CXO

Fixing Frankenstein

Addressing root causes of organic IT issues while at the same time helping management change how they view IT is not easy in small and mid-sized companies. Here are some tips for how to do it.

Addressing root causes of organic IT issues while at the same time helping management change how they view IT is not easy in small and mid-sized companies. Here are some tips for how to do it.

—————————————————————————————————————————————————————————-

A common thread in small and medium-sized businesses (SMBs) is that the company is growing like gangbusters, but the investment in IT has lacked.  The symptoms manifest themselves with a significant increase in fires to put out.  The four or five systems you used to manage somehow turn into 20 or 30 with little or no staff augmentation.  Time spent at the office dealing with server, PC, or application issues starts increasing and you begin forgetting the names of your children.

Unfortunately and fortunately, these companies start with a technology or system that it relies heavily on and over time has been bubble-gummed and kite-stringed since the original build to try and keep up with the business.  One of the symptoms of this practice is that over time, the system starts breaking down. Little things start going wrong: outages, crashes, performance issues, features start taking longer to integrate than to build, etc. Maybe it was built on a spreadsheet or MS Access database and then ported to MySQL or MS SQL without much in the way of optimizing for the new system.

In small companies these applications are not created by a team of developers either. There's usually one person on the team who knows a little programming and who built the system to be a team player and help the company out.  This really talented and motivated team member wants to help so badly that he or she says yes to every feature request that comes down the road.  Before you know it, supporting the application is this person's primary job.  The System administration responsibilities you hired him for are falling through the cracks.

Rule #1 when you start experiencing these issues: Re-architect! Every three to five years, an architecture review should be performed. The hardware may be too old and slow or new features and functions that were once small add-on processes have become much more important to the organization. Re-architecture starts with analyzing how the business uses the application. This changes over time and it's important for IT to stay proactive and regularly check on the viability of the application as it relates to the needs of the business. You may actually find, as the company grows, that a packaged application makes sense. That way, support and maintenance can be outsourced to experts with a deep bench instead of the single developer that becomes a single point of failure.

Each application has a purpose or a strategy that it's designed to fulfill.  So when the business comes to IT and says "I need to add this feature to this application," stop it right there.  Don't let these assumptions cloud your judgment.  Ask the questions:

  • "Should this feature be part of THIS system?"
  • "Does the feature support the overall purpose or strategy of the original application or is it doing something else?"
  • "Is this a feature request that should be part of the application or a request made because the feature COULD be part of the application?"

If you haven't asked those questions in the past, chances are you may have a Frankenstein on your hands.  Just because something could be part of an application (i.e. shared fields, common data elements, etc.) doesn't mean it should.

A little planning up front and proper design will help you avoid all kinds of issues in the future.  Always look for ways to make the application simpler instead of more complex.  Complexity brings with it all kinds of support challenges that can be avoided.  Don't let the enterprise appeal to your IT Hero ego (and, believe me, they'll try).  Again, could you make the changes?  Probably, but should you make the changes?  No.  Giving into the ego stroking will set you up for a hard fall because doing the "I told you so" dance when Frankenstein finally dies doesn't help anyone and could hurt your career.

So a lot of this should be common sense.  But for IT leaders of small and mid-sized companies, having the actual time to do planning and design work is next to impossible.  To make the time, you have two things you need to focus on.

  1. By addressing the root cause, most of the fires miraculously start disappearing.
  2. Management is always going to want the cheapest solution. You need to educate them on the most inexpensive solution.

We've addressed the first focus with the Frankenstein example.  The management focus gets tricky.  If you don't add the feature, IT is labeled as unresponsive.  If you do and there are issues with the application, then your competency is brought into question.  This is the classic lose-lose situation.

Go to management and ask for some help.  Tell them you need to do some planning and focus on these causes that are running your team ragged and bring a solution to the table.  Get some temporary help for three months to fight the fires while you focus on the  causes.  Show them the increase in issues reported and demonstrate your proactive approach for solving the problem.

Now that you have some focus time, objectively find out how valuable the application is to the organization.  Talk to the business users and ask them how important the application is to their job.  What will you not be able to do if the application went away?  Are there regulatory requirements that are met because of this application?  How much would it cost if we were not in compliance?  What would happen if we lost all of the historical data?  What are the "up-time" expectations for the application?  Is there revenue associated with the application?  What is the per-minute cost an outage will cause?  What qualitative issues will be experienced (i.e. customer perceptions, etc.) if an outage occurs?  How long will the outage need to be to realize these impacts?

You can pretty quickly quantify many of these and come up with a value.  Bringing these numbers to management will turn some lights on.  It will also help justify much of the expense that will be needed to bring the application in line with the business expectations.  This will result in four possible outcomes:

  1. Status quo. We accept the risk.
  2. Wow. Maybe we should look at a packaged solution?
  3. OK. Here's some budget to fix the application the right way.
  4. The business needs to reset their expectations and we find a compromise between cost and availability.

Options 2 and 3 would be the most desirable.  Option 1 is the least desirable and option 4 is the most likely selected.  When managing the compromise beware.  Remember e-mail?  Is that a 24x7 application?  Not based on how it is usually implemented, but it is expected to be.

Lack of design and planning for these home-grown applications are the cause of many of your issues.  IT organizations in transition (from small to mid-sized companies) need to have the discipline to focus on the root cause and at the same time change how the organization sees the role of IT.  It's not easy, but hopefully these tips will help.

Editor's Picks

Free Newsletters, In your Inbox