Ensuring that commercially supported systems are kept up to date 5

[jrbarnett]

This is really aimed at people who implement and support commercial systems within their own organisations rather than those who develop and support in house code (I have systems under each of those categories here).

Typically, commercial systems that an organisation has bought into, each version will have its own support lifespan, and at the end of that lifespan, support for that version will cease, and the vendor will require an upgrade to a newer version that is currently supported as a condition of providing continued support for that application.

Such requirements will undoubtedly be outlined in the contract the organisation has signed up to at the time they first bought into the application, and possibly also detailed on their own support website, discussion fora etc. However, they are soon forgotten about and the signed contract gets stuck in the bottom of a filing cabinet somewhere.

While in house support staff can undoubtedly keep people up to date and recommend upgrading said applications to a newer version to the appropriate managers, where the managers have an "If it ain't broke, don't fix it" attitude, the only thing that makes it happen will be logging a support call and being told you are on an unsupported version and please upgrade.

I've already tried getting the boss to add into the annual schedule of work an upgrade to each application to the latest production version of it at that time, but that's "too much work with everything else on at the moment" - which is generally a recipe for a problem in the future.

We have had this twice over the last couple of years and can possibly see it happening again in a few months time if we don't get a move on with something else; has anybody here got any hints/tips/suggestions to ensure that upgrades are carried out in good time before supported versions go out of support (which ends up with a rush upgrade going live not being fully tested, which brings its own issues)?

John

 

[kmcferrin]

In most cases the approach that your boss has taken is what happens. The problem is that upgrading to the latest version usually costs money (at least in labor, if not in licensing as well). Why spend money to fix something that still works if you don't have to?

Frankly, trying to upgrade every commercial application every time a new version comes out (or once a year) is a ridiculous amount of effort. There's an 80/20 rule in IT which basically says that most companies spend 80% of their IT budget on maintaining existing systems and only 20% of the budget on new technologies or new solutions. If you wanted to upgrade every app, every year, it would be more like 100/0.

Most commercial application vendors try to have a new release (even an incremental release) at least once a year. But in many cases the commercial application vendor will have a support cycle that spans several generations. In other words, when they release version 5.0 of Widgetsoft, they still offer support for version 4.0 (the previous current) and version 3.0 (one former revision). When they roll out Widgetsoft 6.0 they'll kill off support for version 3.0. In a situation like this it only makes sense to upgrade if a) the new version offers functionality that you need, or b) the old version is so old that it is no longer supported. So with a cycle like this you could get by with doing upgrades every two years, or possibly longer.

The best course of action is to create an inventory/matrix of all applications in use in your organization, the version that you are using, the EOL for support for the version you're using, the latest version available, and a brief description of the application's function as well as the internal application owner. Every six or twelve months update and review the list with management and application owners and let them decide what action, if any, needs to be taken.

The reason is that not all applications are equal. If a particular application is not critical to the business and has been trouble free for two years they probably won't care if it isn't supported anymore. If it is a critical line of business application, they'll probably want to upgrade it regardless. There are probably multiple cases that lie in between the two.

The most important point is to have visibility into the problem of supportability so that management can make informed decisions and prioritize upgrades.

________________________________________
CompTIA A+, Network+, Server+, Security+
MCTS:Windows 7
MCTS:Hyper-V
MCTS:System Center Virtual Machine Manager
MCSE:Security 2003
MCITP:Enterprise Administrator

 

[jrbarnett]

Thanks kmcferrin,

Will try and do that next week - list out our commercial apps and when support on the current production version ends, then work on a schedule from there.

You are right in that not everything needs to be done every year, but the list should be reviewed on an annual basis, adding in and removing applications as necessary, and changing their importance status if applicable.

John

 

[jAndroid]

Hi jr,

I sense a degree of frustration here from your view-point, mainly because I have experienced such frustration during my working life; whereby management ignore business-critical management actions until: IT HAPPENS!

Then, they are suddenly keenly interested in 'risk-management', serious to seek-out the employee responsible for not 'doing their job properly' (in order to deflect responsibility from themselves).

I get an inkling that kmcferrin may well have 'management' responsibilities from his / her management-slanted response. (or it was very well put from a PR perspective).
E.g. "The reason is that not all applications are equal.", when the actual reason is mainly that non-technical managers 'cut-costs' and ignore experts.

In this case, of course management will be absolutely at fault, but, management WILL blame you nevertheless - because they have the authority to do so.

After saying this, kmcferrin's solution is the only solution, but he / she neglects to tell you how to MAKE SURE that management are forced to recognize that you have offered advice at least.
I.E. producing an inventory/matrix takes a good deal of time (I know - I've experienced exactly your scenario). Will your manager allow such time when he/she has already indicated that the risk doesn't exist?

Either way, the solution to ensure that 'blame' is attributed correctly is via stating your idea via email and storing the response to your personal email account.

If you are warned not to email such advice to your manager in future (e.g. 'tell me vocally'), then escalate the matter with higher management - stating your reasons for wishing to do so (for the sake of risk-management on behalf of the company).

kmcferrin is half-right, but make sure you're covered; you've acquired your technical position through hard-work: don't let bone-idle management palm-off their poor-decision making responsibility on to you - because when IT HAPPENS - they will!).

Good luck,

J

 

[edfair]

I suspect that I don't have a customer with current level applications except for anti-virus signatures which update automatically.
When it gets uncomfortable enough (for me) they either upgrade or accept the risk. Like it or not, the manager that stands in the way of upgrading gets hard copy of the risk factors. I don't stop supporting them, just make sure that they can recover to the same level, and let them stew when currency becomes a problem.


Ed Fair
Give the wrong symptoms, get the wrong solutions.

 

[kmcferrin]

E.g. "The reason is that not all applications are equal.", when the actual reason is mainly that non-technical managers 'cut-costs' and ignore experts.

That's a bit of a stretch. When I say that all applications are not equal, that's the truth. Let's compare two applications. Let's say that one of them is an application that isn't essential to the business, but it is essential a a group of three people whose job it makes much, much easier. Let's say that the other application is the central CRM/order tracking system that the business runs on and is used enterprise-wide. I think most reasonable people would understand that the CRM/order tracking system is far more important than that other small application (probably more important than most applications). If it comes down to needing to choose between two systems, guess which one is going to get priority?

It's not that I come from a manager's standpoint or that my opinion is slanted incorrectly. I'm a consultant and after many years of working with businesses I have come to a certain set of beliefs. One of them is that management will never completely understand IT. They think of it as a utility like electricity. The second one is that IT isn't the center of the universe, and it doesn't exist in a vacuum. IT is there to facilitate the business, to make it more efficient and ultimately profitable. Because of that, in most cases the needs/desires of IT need to be balanced with or come secondary to the needs of the business.

You seem to have a very anti-management bias in a lot of your responses. I'm assuming that it is a by-product of the situations that you have been exposed to in the past, but it isn't fate that there should be such an adversarial relationship between IT and business management. Don't get me wrong, I've said that I don't believe that management will ever truly understand IT. I believe that. But I also believe that IT's role is to help management make the best (or at least most informed) decisions that they can make. You want to keep them from performing any shotgun podiatry, if possible. It's certainly possible to take a proactive approach that helps management make good decisions and makes IT look good for facilitating those decisions.

To be honest, most of the problems that I've run into in IT are with either IT or business managers looking at things as a zero sum game. Every interaction doesn't have to have a winner and a loser. If you can work together to make the business better, you both can win. You have to keep that in mind. It can be difficult to do, especially because IT work tends to attract a certain arrogant mindset (WE know what's right, WE know what's important, YOU WILL do things OUR WAY). I'm happy to say that in most cases that tends to be more related to career immaturity, and that as people gain experience they tend to gain the ability to look at things with a big-picture view.


________________________________________
CompTIA A+, Network+, Server+, Security+
MCTS:Windows 7
MCTS:Hyper-V
MCTS:System Center Virtual Machine Manager
MCSE:Security 2003
MCITP:Enterprise Administrator

 

[CajunCenturion]

Well said, kmcferrin.


--------------
Good Luck
To get the most from your Tek-Tips experience, please read
FAQ181-2886
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[jrbarnett]

OK, here goes - very brief summary of the top level those I have quickly identified today.

System A - Payroll/HR/Pensions management; current version out of support Feb 2010. Affected areas: HR/Payroll & pensions for system users; knock on effects of all staff in organisation when it comes to calculating tax correctly for staff pay and student stipends and payslip/P60 production.

System B - Student management; current version out of support May 2010. Affected areas: Student registry, IT Helpdesk (network access controlled through this system based on status and course dates). Potential knock on effects of not doing it - unsupported configuration by vendor if issues arise.

System C - Finance/Supplies management; current version out of support July 2010. Affected areas: Finance, Supplies. Potential knock on effects on rest of organisation including billing/payment of suppliers, student tuition fee invoicing, internal recharges and internal budget management.

You tell me which of those is "less important than the others" to my situation? I work in a college of a well known University.
Tbere may well be fewer knock on effects with system B, but a new version is released every 6 months with a product lifespan of 18 months from first public release through to end of life.

John

 

[kmcferrin]

Well, if those are the only three applications and I had to choose someone who has to wait, I would go with option B. Option A certainly seems to be the most critical. But then it's not my place to make that decision, I'm not running the show at your place of employment.

If I were the manager I would probably want to know what the current versions of those apps are, when the next version is expected to be released, and what the support lifetime for that is expected to be. Then I would want to work out a schedule to remediate the applications based on priority. It may be that you've just hit a perfect storm of planned obsolescence that occurs in 2010. If some products have a longer lifecycle then you may not run into those issues going forward, but it sounds like the issue may have been neglected so far.

Of course, it could be a funding issue too. There might not be enough manpower or money to handle all of the "necessary" upgrades. If that is the case then there's not much that you an do. You can either do the best that you can with the resources that you have available or you can do nothing. Unless you personally have the authority to make those decisions you're pretty much relegated to telling the story to your management. Just make sure that you outline the concerns and risks for each application. Who knows...maybe the manager was unwilling to take on the work only because he doesn't understand the ramifications, and he may change his mind.

________________________________________
CompTIA A+, Network+, Server+, Security+
MCTS:Windows 7
MCTS:Hyper-V
MCTS:System Center Virtual Machine Manager
MCSE:Security 2003
MCITP:Enterprise Administrator

 

[SQLSister]

I would formally document the request to upgrade the software. Make the manager be the one to tell you in writing not to upgrade (Amazing how fast this can change someone's mind).

Make the formal request with a document that outlines when the apps will go out of support, the types of support you have used in the past, how long the project to upgrade could take and the risks of not upgrading.

Once the manager understands that the risk of not upgrading the payroll package is that his personal paycheck (and his boss' personal paycheck) might not get generated on time because there was a problem and we couldn't resolve it without support and they wouldn't help us until we upgraded and counting the approval time to spend the money and the actual time to install the upgrade and test and then resolve the issue, payroll would be a minimum of two days late if the systems is not maintained in a supportable state. (Gah, sorry about the run-on sentence)

Remind them that lack of upgrades might also mean legal issues in some of these systems. No upgrade to payroll systems might mean new laws affecting pay and benefits calculations are not applied.

Go into as much depth as you can find time for in showing the real world risks of not upgrading. It's a brave manager indeed who will take the risk in writing of making the CEO's (well in your case the Dean's) paycheck late.

The beauty of formally requesting an upgrade is that they must answer yes or no in writing and then the fault is on their shoulders. This will often serve to generate action when a verbal request will not.

"NOTHING is more important in a database than integrity." ESquared

 

[rosieb]

Nicely put SQLSister!

John

As you well know, I have a similar problem, but generally I just schedule the upgrades - usually there's statutory requirement buried in each and the costs are just resource time.

However I have recently hit a problem, servers not upgraded from Server 2K, no longer supported by the vendor - we lived with that for a year, despite my complaints. Now, upgrades won't run on that OS... Sudden panic, and the budgets that were tight last year are infinitesimal this year!


The only route is to put it in writing - with the risks, and ask for a decision on where/if the money is spent. It's not for you to make those decisions - just make sure you keep a copy of the correspondence!




Rosie
"It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong." Richard Feynman

 

[58sniper]

I only took a quick look through the various replies, but I can tell you what generally works for me. In many environments, orgs have a defined lifecycle for hardware. I generally tell orgs that you want to replace hardware when it's about to fall out of warranty. That way, you always have hardware thats covered by the 24x7x4 warrant.

When a server is due to be replaced, that's a perfect time to look at version upgrades for applications contained on that hardware.

Let's say hardware refresh is 3 years. So, every three years, you get a new server. And on that new server, you're going to at least WANT to install the latest Operating System. That brings up other issues, not the least of which are anti-virus and other similar components that need to be evaluated for compatibility with the new OS. Then we look at your application - is the version you're running supported on the new OS? If not, you either have to install a legacy OS, or upgrade the app (or not refresh the hardware). If yes, then you decide if you want to upgrade the app or not. As was mentioned previously, the org needs to evaluate what a new version will provide - support; features; performance, and weigh that against the costs associated with upgrades.

Some apps will remain critical, but are no longer commercially available or supported. When it comes time for hardware refresh, this can be troublesome since the legacy OS that's required may not support the components of the new hardware. At this point, virtualization is sometimes the answer. Other times, the existing hardware/software solution is just left in place.

From a strictly software standpoint, I always recommend that all hotfixes, service packs and enhancements that are available be installed when possible. This helps avoid problems, and most of these are no cost. Version upgrades are evaluated based on ROI and TCO. Remember, licensing is just part of the cost. You also have to look at manpower for implementation, testing by pilot users, migration of data, etc.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[flapeyre]

Just think of where you would be if you blindly upgraded to the latest and greatest version of Windows as they came out. Right now, most of our PCs are on XP, even new ones (we downgrade them from Vista). It's far easier to image XP on a new laptop than it is to fix all of the apps that work on XP and make them Vista-friendly.

For that matter, we don't even use IE8 yet until we are sure that it won't break anything we already have running.

Test, test, test... then upgrade.

-- Francis
I'd like to change the world, but I can't find the source code.