Blade Watch

I was having a chat with Chris yesterday over coffee asking him this question, “Who should be doing the decommissioining?”. This is in reference to a role at a bank that I heard about from a colleague, they’re looking for someone to come in and put simply speak nicely to application teams, look at their applications, their servers (and the server estate) to see what can be decommissioned. The questions are in bold, the responses immediately below and as ever to keep Chris’ identity in Canary Wharf secret, we’ve removed anything too specific.

So who decommissions?

The application team right? They tell us when a server is no longer needed and we then archive it, submit it for removal and disposal.

Fine, but what about the ghost servers? The ones that are ‘in use’ and the infrastructure ones?

Well I think it all comes down to the ‘designated owner’ knowing what servers they have, what they do and if they’re needed, afterall they pay per server for support, I think it’s only a few hundred pounds, whether the server is on, has an operating system installed or if it’s the company web server, they have to pay that ‘fee’ for hosting and support.

The infastructure ones, I suppose IT should be doing that, but typically we don’t have enough budget to have servers sitting around and not being used. There might be those ‘unallocated’ servers, the ones we use to dump files on or host Systems Insight Manager, they’re not providing direct end user benefit, but these are the kind of servers that might typically get re-allocated to solve an immediate need.

The ghost ones, I suppose they get decommissioned when we do an inventory and that’s reported to the application teams that either say yes it’s their server or it’s decommissioned.

Should the Windows and Unix teams not be managing, or owning decommissioning?

Well it depends, I can either do support or inventory work, identifying servers for decomission, those ghost ones or servers that could so easily be consolidated, but there are a few issues:

Budget/sign off – it requires investment, not necessarily a lot of money, but maybe a few servers/emulex or Q-Logic cards, and that all needs sign off, justification/debate

Ownership – with data center space as it is, there’s the tendency for applications to keep servers ‘in case they need them’ it also means that they have ’store credit’ to get in a new server, by keeping that Compaq 6500 as a file server for development, when I need to get that server installed, I can say I’ll virtualize the 6500, and then use that space to get my server in the store.

Priorities – what is deemed more valuable to the business, to my manager, my department? The CIO just wants calls resolved and the volume of calls reduced, improved work-flows, decommissioning is important, but on the basis that data center space will always be ‘an issue’, does having an engineer spending a day a week for a year looking to decommission or consolidate add value, or reduce opportunities for investment/project budget?

Should there be a decommission team?

I would say yes, but by team I mean a team that owns the data, that owns the infrastructure in terms of defining who owns what, what is production (customer facing) and not, owning the quality, accuracy of data, so that the production teams can focus on their job, and have a team that own the installation, management and decommissioning of the server.

Isn’t that the server team though?

Well yes and no, the problem is as the infrastructure gets more complex the typical inventory that the server team own so to speak, isn’t necessarily what is wanted by the end user.  Ask me how many servers we have, we can do that, how many servers Fixed Income have, again fine, but ask how many servers are owned and billed to business line A, with their environments, server type and serial number and we’re moving away from a support to a reporting and management function.

Some interesting thoughts from Chris on decommissioning.  I wonder if the issue is not one of complexity, ownership and reporting. In the olden days, there might be two types of network, customer facing and internal, Windows and Unix, nothing ‘complicated’, the servers were owned by typically one server team per platform, so knowledge of the infrastructure, reporting was simple.  As we move to white labelling, as we move to business areas owning the infrastructure, where Fixed Income might ‘own their servers’, how does that affect process/support/reporting? When those servers get moved to Manchester and are renamed from GLSS000011 to MNSS000011, who notifies who, what about monitoring, billing, Systems Insight Manager/IBM Director. The audit information, the change process, how does that work? By installing Oracle on the blade farm, do I need to notify the central Database team?

As we evolve the business, what we do with the infrastructure, we need to evolve those back office IT functions, empower individual teams to ‘own’ their infrastructure whilst, ensuring standardized platforms conforming to basic agreed security/IT/production standards, to maintain the benefits of economies of scale and at the same time allowing business requirements to drive change and delivery.

As we move to a cloud platform, whether it’s the Amazon/salesforce.com scenario or a private cloud, within the enterprise, does it matter who owns the infrastructure? What the infrastructure is? Should the cloud provider not be concerned with such things internally, to the customer focussing on customer delivery and flexibility?

Related posts:

1. Talk of everything being virtualized makes me nervous I was having a chat with Chris (he’s in a...
2. Interviewing an app guy (part 3 of a phased approach)   So we left Chris with his BAU hard hat...
3. The Bladewatch CMDB tool announced! IT rocks and we’ll be announcing more soon! Over the last few months and since I’ve began writing...
4. Just cluster it the good man said I was talking with Chris today to see how he’s...
5. Interviewing a CIO (part 4 of the phased approach) So we left our app guy, wanting to own his...

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