IT Cost Cutting Pressures
In the age of constant cost pressures within regulated industries (especially Pharma), IT departments are being asked to do more with less. (Translation: We're increasing your workload and cutting staff so don't sign up for that 5:00 Pilates class.)
But sometimes the answer has less to do with utilization of staff and more to do with utilization of servers. From a cost savings perspective, this is the true low hanging fruit. (Why is it that fruit gets all the glory? And what about tomatoes? Low hanging tomatoes are rotting on the ground.)
Server Proliferation
Often companies implementing new applications would follow a "one app needs one server" mentality. This is sort of like saying you have to take five kids to baseball practice and so you simply go out and buy four more cars. Seems like a waste of money and totally inefficient, right? That's because it is. Not only did you just waste money on the purchase, but you still have to fuel, maintain, insure and garage those extra cars. Servers and data centers are the same.
Consolidation: Why and Why Not?
So if it is all so obvious, why isn't server consolidation considered more often? Gartner estimated a few years ago that corporate servers run at a 20% capacity. A manufacturing manager wouldn't accept that situation in a production environment and IT managers shouldn't either.
In regulated industries, especially life sciences, there may be many reasons but typically one common one. Fear.
Remember our last blog about IT versus QA? FDA and audit guidelines practically scream "Don't touch that qualified server or those validated applications because we're watching you!"But it doesn't have to be that way. Granted, when FDR said "the only thing we have to fear is fear itself", he probably wasn't looking at a stack of non conforming reports from a stringent FDA auditor. But using Good Systems Practice (GSP) with a solid change management foundation combined with an understanding of when you should and shouldn't combine applications can make the whole process less risky and less costly.
For example, you shouldn't put your office applications on the same server as your clinical research data because that's just asking for trouble whenever you make a simple change to the office application. Sort of like avoiding having your salad on the same plate as your filet mignon. (Is this blog making anyone else hungry or is it just me?) But an assessment of your in-use applications and the current server set-up can help design a server consolidation plan of action that will work for your business needs, your regulatory needs and your financial goals.
Virtual Servers
New technologies in virtual servers increase the possibilities. Products like VMWare or offerings from HP, Sun and IBM create the behavior of application partitioning without the increased hardware purchases, and space requirements.
A short assessment is a good place to discover where to start your server consolidation project as well as help you identify that low hanging fr….non-vegetable and determine if you can take advantage of a virtual environment. We can help you with that. For more information on steps necessary to start saving money by eliminating things you don't need instead of people you do, see our white paper at www.csdg.com or contact me through blog@csdg.com.
We welcome your comments and questions here at the Round….even if you want to throw tomatoes.
The Marketing Maven.
Copyright© 2007 Court Square Data Group, Inc. All Rights Reserved
Technorati tags:
ITIL
Good Systems Practice
Qualification
Validation
Gardening
IT Regulations
21CFR11
FDA Audits
Pharmaceutical
VMWare
Server Consolidation
2 comments:
The car analogy obscures some of the reason why the one-app-one-server model developed and has persisted.
It's really more like having 5 over-achieving spoiled brats who can't be in the same room for 5 minutes without starting a fight/international incident, and who also have 80-hour weeks between dance, band, karate, school plays, and toastmasters.
The apps really did not get along well - in fact, they still don't. Despite all the promises of .NET and Java about everything running beautifully side-by-side in parallel versions, DLL hell is still a very real place. And that's not even bringing in issues of performance or hardware requirements.
But the biggest issue is not compatibility or performance, but uptime. Again, despite all the promises, Windows servers still need to be rebooted fairly often when apps are changed (and before the MS-hate starts, note that this is mostly the fault of the app developers, not Microsoft...). If your services have 5x9 uptime requirements (99.999%), you really don't want to have to take an outage on Service A, which is not being changed, just because it happens to be installed on the same server as Service B.
So there were good reasons for the one-server-one-app policy, many of which continue to be true today.
And that is why VMWare and Microsoft's Virtual Server are huge topics in server consolidation. Virtualization was the first technology since Windows NT started the explosive proliferation of servers to provide a real chance at getting servers back to efficient usage of hardware resources.
Virtualization isn't a silver bullet, though. There are a lot of issues to consider when virtualizing a server environment - all the same kinds of things mentioned above: performance, uptime, security, compliance. When executed by people with the proper expertise, it yields great results, but it's by no means trivial.
I think the biggest issue that I have seen with consolidation is that each app stores and formats the data slightly differently. Thus consolidating legacy data is an expensive data warehousing migration task.
The data services layer is supposed to solve this issue but there has not been much product development that I have seen yet. Perhaps the most promising is a metadata langauge called JUMP. The open-source effort on sourceforge (project jumper http://sourceforge.net/projects/jumper) holds some promise that the industry might actually agree on an open-standard.
Post a Comment