Storagebod

It seems the more that I consider the architectural and technical challenges and changes to the Corporate IT world, the more I come back to the cultural issues which exist within many IT departments and the more I find myself feeling strongly that this is where the work really needs to be done.

Unfortunately it is pretty hard to buy a culture from a vendor, even though I suspect if Chuck could work out exactly how to do so; we’d have a product from EMC called V-CLT (or is that VMware?); so building a culture is going to be have to be an internal thing and that means it is going to be tough.

Too often the route into IT Management means either promoting excellent techies into management or sometimes promoting people into positions where they can do no more harm as opposed to moving people into positions which suits them and their personalities. I am sure that we can all think of examples of both; this is especially true in end-user organisations as the career paths are less varied than that of the vendor organisation. Vendor organisations have sales, marketing and other avenues for progression; they also have the traditional IT paths as well.

But all IT organisations are suffering from cultures which neither scale or are sustainable in the long term. There needs to be a long term shift which ensure that training and development are in more than just technical skills; there needs to be a move away from a hero culture that sees staff at all levels of an organisation regularly halving their hourly rates by working longer than their contracted hours, not taking leave and forgetting that you ‘Work to Live’.

Careers need to be thought of more than the fastest route to the top and when people find their natural level; this does not mean that they do not stop being valuable members of an organisation. Work on developing people horizontally (and you with the dirty mind can stop sniggering); I think that there is something relatively unhealthy when you find managers who have worked their way up through a team and only worked in one team.  Horizontal moves have immense value; I have learnt such a lot in the past couple of years running a test team as well as a storage team.

Horizontal moves will help to break down some of the siloed mentality; even if you do not believe in DevOps, moving people between these two disciplines even on secondment must have value.

If you have a graduate scheme in place, the natural roles that most graduates gravitate to are in development; make sure that they have a placement in an Operations/Infrastructure team. They will learn so much.

And if you work in management; you are doing a pretty hard job, make it easier on yourself by standing on the shoulders of giants and actually study the art of management and leadership. Most get to management by being good at something; being good at that something does not mean you know anything about management.

If you start an architecture with a shopping list of technologies that must be used; that architecture will be compromised. However this does not mean that you start working without an appreciation of the possible, obviously you need to be aware of limitations such as constants such as the speed of light and other real constraints.

But currently I see a trend from many, both vendors and users, trying to fix round-hole problems with square-shaped blocks. Not enough time is spent on the problem definition and truly understanding the problem; your existing tools may not be sufficient and although it may feel that it is more expensive to implement something new, at times it might be cheaper in the long-term to implement something right.

Also be aware of falling into the trap of implementing a feature just because you’ve made the mistake of purchasing something that does not fit your problem definition. If you’ve been sold something that you can’t use effectively, you have a couple of option; suck it up and learn from experience or shout and holler at your vendor/partner for selling you something which is merely shelf-ware. In my experience, the latter is often ultimately pointless and simply results in the vendor promising you some other product which you put on a shelf and not use. Use the experience to move away from architecting to utilise a feature and architecting to solve a problem.

This does not mean that you simply purchase a new system/technology for every problem; governance has a role but I would suggest that governance should be applied after the initial high-level-architecture. I like to think of it like more more traditional bricks and mortar architecture; the architect relies on a whole bunch of technical people to fulfil their vision and bring it to reality. At times these technical people will tell the architect that the architect is a complete moron; sometimes the architect will agree and sometimes the architect will work with the technical teams to come up with something innovative and new.

But in general the architect does not start their design with a specific make of brick in mind. Neither should an IT architect.