Bladewatch.com

I have always loved history. At university it was between history and IT, I went with IT and resulted in my current status. Anyway, this url covers a topic that I wanted to talk about:

“For want of a shoe the horse was lost.”

Why?

I had an interview with one of the managers from a financial organization which is undergoing organizational change, (many of the banks are, as a result of mergers and acquisitions or costs cutting), as part of this he told me of some challenges facing him.

I run the database team, we install the database products and configure the systems ready so that we can migrate the application databases to the new servers. There are a few hundred servers being installed, moved and rebuilt as part of the re-organization, however the standards have not been agreed and set.

One enterprise standards support Ingres, Oracle and SQL, the other supports only Oracle and SQL. (This issue is across the IT department, middleware and the Windows/Unix guys all have different standards of layered products or configurations), resulting in two choices:

1. We either delay work until standards are set and agreed.
2. We simply continue business as usual.

This results in an issue, we either get accused of delaying projects, or we face the conversations later when we state that an application is out of support as it is using an incorrect database platform.

For example, we deployed an Ingres database server last week, IT has charged them two days time to configure the database, migrate the data and set it up. If we no longer support Ingres, the business will get told you need to migrate to Oracle, please change your application code, please purchase a new server, database and middleware, then allocate a few days time for us to migrate to the new server with Oracle.

At the same time, I need to bring all SQL servers to the same service pack and make sure they are all patched, but since we haven’t signed off which database platform we’re keeping, I’m reluctant to dedicate an engineer or two to upgrading the database servers, this of course means we’re moving out of support on our SQL platforms.

The lack of a binary statement, of standards therefore is going to result in duplication of effort long term, unnecessary cost and that challenge of ‘staying still’. The teams wont want to make significant changes to the infrastructure or service improvement plans until they understand the strategy, the direction we’re going on, in the meantime the IT function therefore becomes at risk of standing still and not continually evolving not just their offering, but the platform.

Interestingly it’s not a technical problem. It’s a managerial resourcing and strategy problem. As a result of IT and management having not agreed or published the basics, we undermine the business as usual and project work, the vehicles we use to deliver.

The organization begins to stand still – I can’t make decisions because I don’t know where I will be in 6 months, I wont make the effort on that because we might not support that in future. In these situations we need:

• Guidance – binary in nature – yes/no answers to what’s in scope, what’s supported and not
• A focus on business as usual – evolution and improvement of the platform continues – never stand still
• Isolation of the business as usual/project from organizational changes (as best as possible)
  • Where we are, where we are going too – the quicker the announcements are made the better
  • What core layered components, database and operating system are supported
  • What business as usual projects continue -  service pack/layered component upgrades etc

No related posts.

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