Bladewatch.com

In the previous article, the BAA CIO had mentioned ‘complexity breeds costs’, and in many ways he’s right. There are two main reasons your IT costs are higher when compared to the industry benchmark, and they link back to investment and management. Both can be easily resolved from an operational standpoint, often it’s an update of processes, of making systems communicate, coupled with specific investment in target areas to reduce delays in deployment and support, an agreement in essence of standards and best practice.  We’ll go through what I mean by that in a moment, but let us examine the management aspect.

In terms of management we’re talking about the way we do business, the cross charging element, the structure of your organization, how things are done both in terms of ‘the process’ and how it works in reality, how many layers and departments are involved in that specific activity. The more people there are to involve, the slower the process seems to be. What we need to do is attack the challenge so to speak from three ways;

1. Process based change – the actual workflows involved from the point at which the user emails the helpdesk and says order me a desktop to the point at which it is delivered and installed.
2. Organizational based change -  what barriers to success are there, and key what teams are not performing, how we might change that.
3. Technical based change – what tools/systems prevent or ‘don’t help’ us deliver that request.

The next post illustrates this wonderfully.

In terms of technology we need to be covering the fundamentals, it’s the basics, your core which underpins everything else. Let me be clear when we say core, your network, your storage, desktop/server, middelware and database. If we have a fundamental issue with the server build, that it takes too long, that it hasn’t moved on in line with server standards and specifications, that can all hinder your success. A network where I have to set the buffers to high, where multi-casting works, but just not quite right, just not enough for my application guys to be happy with, means that we’re starting off with an uneven dare I say it, unstable core. It is this core dear reader upon which you may be powering your business, running your applications and wondering why that email took 15 minutes to arrive, why we had to reboot the settlements server during the business day, and just WHY OH WHY IS MY DESKTOP SOOOOOOOOOO SLLLLLLOOOOOOOOWWWW.

So when we look at the technology, we should be working in split personality mode. I want my support guys looking at what we having and striving to stabilize the core:

• Upgrade all drivers and firmware on everything, even if it’s out of support, that we have our systems optimized regardless of whether they’re a DL380 G6 or DEC 1200A.
• Upgrade the operating system with the latest service packs, security patches – again even if it’s out of support, I don’t care if it’s NT4, but can we at least consolidate to Service Pack 6a with the roll up hot fix. I don’t care if it’s Solaris 8, just make sure it’s patched as high as the application and the box will go.
• Identify and resolve configuration type issues, that server19 runs out of disk space due to the pagefile, move the page file, upgrade the memory. we should be configuring on a per application per server basis, there should be plenty of disk space on the OS drive, the database dumps/backups and applications should all be configured to work within the constraints of that server, whether it’s 4GB or 146Gb drives.
• Defrag, defrag, defrag, why? Because it’s one thing that we can do during the business day (application permitting) to improve/contain performance without impacting operations, let us do what we can.
• Reboot, reboot, reboot – avoid that manliness nonsense of “my server has been up longer than yours”, I don’t care if mine works. Should a server stay online for months/years without rebooting? Yes. But on the basis that it’s 2009, life is short and my Bentley will not be delivered on the basis of the uptime statistics of my infrastructure, I can either security patch/service my server estate and reboot it once a month or even every three months, or we can, during that key transaction, reboot it, because it’s hung and the anti virus isn’t updating, the server having been up for 700 days.
• Get on with it – do it, stop talking about where we are, what the barriers to success are, how that isn’t my specific job, that’s not a support task, who’s budget should fund it, middleware should really be doing that under section 7.4 because it’s their remit. We can either do it, fix it, and move on, or continue in mediocrity, but let known that users/the business don’t tend to reward failure.
• Understand each business lines’, each user groups priorities and change the way you deliver and interact accordingly. We could argue with front office since they don’t like filling in the change request, or we could just fill in the change request, understanding that by doing this, I expect assistance/the benefit of the doubt accordingly.

There will be a post illustrating this later today.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.