Get email updates every time we post!
http://weblog.infoworld.com/real-time-enterprise/archives/2008/03/datacenter_in_a.html
One of the biggest barriers to innovation today, is dealing with current datacenter complexity. This forces the largest IT investment dollars to be focused on keeping the lights on and containing infrastructure sprawl. The inability to focus a majority of time and investments on innovating and differentiating the business thru IT causes continued missed expectations and disappointment within the business user community.
It is essential to understand that past design choices resulted in complexity, waste, performance barriers and cost models that don’t work for the customer or best in class distinction. The lack of transparency of what has been done in the past and how datacenter build-out continues to be a “don’t change†mindset – results in continued misalignment with business needs. This prevents business agility and reduces shareholder value.
Check out this great article from infoworld talking about the data center. It’s interesting topic of discussion for a mixture of reasons. I’ve often thought about this, but like to turn it around a bit, mix it up with the business viewpoint and suggest another way. Could we not have business transformation through data center transformation?
Could I not have the ability to fail over the data center, the IT infrastructure wherever the power is cheapest, which allows me to do data center wide updates in terms of security patching, systems upgrades, application releases? Think about it, I could deploy the application code to Sinagpore (when it’s offline), have my developers test it, and have it signed off ready for the Singapore users to come in, switch on and find their now on version 6.81 of the organization trading portal. Where we can fail over applications between sites for functionality, for performance or availability; “New York grid is bigger than Hong Kong’s, so Hong Kong use New York when they close for the day”.
If we want to truly take the data center to the next level we need to align the IT to the business and the business to the IT. Our architecture (usually application architecture and infrastructure architecture), our strategy needs to be done at the high level, at the business level with (and this will sound binary, harsh/lacking in due thought – please stay with me), rules applied from the top down, we need to fix the cost of IT by moving to a service provisioning model. Granted we can’t do this overnight but we can move towards the concept, gaining savings in energy efficiency, hardware support cost and evolution of the platform. What I mean in essence firstly is to do the adhoc rule number 9 type thing:
Right why these rules.
A server older than three years is typically performance per watt wise giving you a poor return on investment, it’s contributing heavily to your hardware support contract, and giving you pound for pound less value than a newer server in terms of cpu,ram and storage. The 6 year old DL380 might be perfectly adequate for your application needs, but then does this application need that u space, that power? Could we not have a new box hosting three of these applications in a virtual machine?
Let’s abstract the user, the application from these issues.
Additionally, I don’t want people tied to the server, I don’t want application code that might be sticky, or dependent on build version 7.1.3, I want the server to be seen as a means to an end, a processing device, in essence a glorified desktop that we swap regularly to give you the enhanced functionality and performance you need. To keep evolving the operating system in line with support and allow me to be more efficient in the data center and reduce the hardware costs. In doing so we move to a model of abstraction from the tin, granted we still need server78 for equities, but if I deploy server 439, they should be able to port their code to the new server. With the ability to port the applications, porting them to grid, to Citrix or web should be the next step.
With these rules in place, I can then implement the smart technologies, the smart processes such as consolidation, virtualization or even grid, or the shared infrastructure. With directive, with buy in from the CEO level, I can approach that application team and say, “Hi, you’re running a DL380 Pentium 733 with 256mb ram, running your web site on Windows 2000. You can either request a new virtual machine, a new physical server, or switch to our shared web farm.”
Let me explain the buy in thing. If the CIO mandates all servers over 3 years old must be decommissioned, and is then indirectly or directly over-ruled by business line A, application team B, you undermine the CIO’s ability to drive through change. Now obviously change needs to be actioned in line with business need, in line with the constraints organizationally and from the application. But with CEO/board level buy in, we can be infrastructure led, we can be dynamic, focused on deliver, looking at the big picture, not in the situation where application A haven’t got budget to buy a new server, so we’re rebuilding a server which is relatively energy inefficient (performance per watt), which lacks lights out administration, the ability to host the newer operating systems and support the memory configuration that might be needed in the near future. At the same time, it’s using your organization wide data center space, Application C which uses the latest and greatest is in effect you could argue subsidizing application A. Fine, there are situations where this is the cost of doing business, where upgrading the application code would cost more than the ‘fixed support cost’, but can we not limit our exposure, in doing so limit our operational costs? Focus on revenue generation?
No related posts.
Related posts brought to you by Yet Another Related Posts Plugin.