The Most Common Gaps in IT Strategic Plans

Author
Peter Welcher
Architect, Operations Technical Advisor

Your IT team probably has an IT strategic plan, and updates it annually. If not, I have some homework for you…

Let’s start with the obvious: An IT plan needs to align with your strategic business plans, so begin with the big questions:

  • What are your organization’s top strategic business initiatives, plans, and needs?
  • What are you trying to achieve, short- and long-term, by pursing those initiatives? Added revenue? Increased efficiency or lower costs? A more collaborative work environment? A better product or service?
  • What are the biggest gaps and problem areas in IT related to achieving your objectives via those strategic business initiatives?
  • What new technologies and steps can IT take to make the business more profitable, provide new services, and satisfy customers?
  • How can we do it within our budget, or even while reducing IT costs?

Planning Gaps

New technology is one area where NetCraftsmen sometimes sees planning gaps.

New approaches to customer service, either to cut costs or to provide value added to products (think mobile remote control, management, etc.), are an example. Could your organization use some outside-the-box thinking?

On the technical side, we have been hearing more conversations about “Shiny New Object” syndrome. New technologies always sound great because they’re marketed well. The practical questions concern risks, maturity, complexity, and gain. Many IT or network managers desire greater simplicity and better productivity. Network design can certainly help with that. Pockets of automation might help, too, but network automation isn’t quite there yet.

As a practical example, there’s a lot of buzz lately around active-active datacenters. They’re potentially a great idea; much less risky if done at Layer 3, leveraging Load Balancers, than at Layer 2. Many existing deployments require some Layer 2, due to hard-coded IP addresses in applications, medical applications (still) built on Layer 2 High Availability technologies (aka “Sort Of Highly Available but Fragile”), and the like. Yet others are being driven by desire for VMware vMotion of anything anytime, which usually violates the laws of physics or is a real budget-buster (requires massive inter-datacenter bandwidth). If you hear vMotion at will, have your VMware start checking the bandwidth and replication realities.

My point: the answer is not always clear, requires some discussion and possibly executive decision-making based on facts, what it buys you, risks, and costs.

Another area where planning can suffer problems is old technology replacement. Do you still have FastEthernet interfaces in your datacenter or network? Should you? Isn’t the network gear involved getting pretty old? If your network is using mostly Gigabit links, any traffic sent to a FastEthernet-based server can crush the FastEthernet link. Sometimes staff is so busy deploying new things, the old stuff never quite retires. A fresh set of eyeballs might spot all those “we’ll retire it when we replace it” projects that are still lingering around.

Speaking of legacy technology, does your planning incorporate retiring accrued technical debt? One of the biggest problems in IT is the “80% done” project, where the old technology isn’t… quite… gone. Maintaining the old stuff consumes staff time. Not good! The big invisible elephant in the datacenter is usually flat backup networks, prone to spanning tree loops, and sometimes a quiet backdoor bypass to security as well.

Another issue we sometimes see is technical unawareness, either as to suitable skills or Best Practices. Sometimes a technical lead has big ego along with poorly informed opinions. Other times, staff sets too low a bar on “expertise,” or just has been too busy and is not aware of new ideas, new Best Practices.

For example, we still see office campus designs that don’t do Layer 3 to the closet, or that have VLANs spanning both user offices and the datacenter. That’s tolerable, maybe, in small shops; it went out elsewhere around 2000. We still see major hospitals having Really Bad Days due to such designs, despite the fact that Spanning Tree problems have been in the press. Some staff just never got the message!

One last problem item: we believe good design involves balance between Network, Server/Virtualization/Storage, Security, Operational Management, and Cloud. Decisions made with inadequate input sometimes solve a problem in one of those domains, but create complexity or fragility in another, often on the network side.

Additional Questions to Ask

There are some other questions that are, or should be, under ongoing discussion among our customers:

  • Is ITIL / Change Control a gating factor? We’re seeing more and more shops that cannot get Change Windows. Deferred maintenance… see Project Phoenix. Do your plans factor such delays in?
  • Is the network/IT shop keeping up with technology shifts, which are coming faster and faster, or is it falling behind on technology, due to the Change Windows issue or budget/staffing?
  • Is your Disaster Recovery Plan really going to work, or will it work only if several concurrent assumptions are met (limited disaster duration, few other companies affected, regional travel unaffected, etc.)?
  • Do you encourage staff to work remotely via VPN (and/or VDI?)? This could be a vital DR enabler, providing more DR flexibility. (See Thinking Differently about BYOD and COOP)
  • Is your DR environment much different than Production, or are they mirrors of each other? Does DR just cover “critical systems” or everything? Is that difference causing a need for DR planning that does not happen, or failed DR events?
  • Is Layer 2 Data Center Interconnect (DCI) and active/active (Layer 2) datacenter a good idea? What are the alternatives, what are the technical challenges, risks, and complexity associated with each alternative?
  • Are we moving fast enough to the cloud? How do we best leverage the various forms of cloud, and what are the cost implications of our choices?
  • How are we going to manage and secure applications in the Cloud? Is our DevOps team taking that into account in the overall architecture, or are they solely focused on functionality and features?
  • What are we doing to standardize our deployments and move towards automated configuration, code upgrades and patches, backup, replication, bi-directional replication, etc.?
  • Is our network (server, security, etc.) management software doing what we need?

There is a common thread to the above: Getting other opinions and feedback can help avoid mistakes. A consulting firm can provide a second opinion, some vendor neutrality representing your interests, and some idea of Best Practices and what others are doing.

All that is something your staff won’t be able to do, they just have not seen as many IT setups nor network designs as a good consultancy does. We’re here to help, so feel to reach out.

Comments

Comments are welcome, both in agreement or constructive disagreement about the above. I enjoy hearing from readers and carrying on deeper discussion via comments. Thanks in advance!

Twitter: @pjwelcher

Disclosure Statement
Cisco Certified 20 YearsCisco Champion 2016

 

 

 

Leave a Reply