Back before the interweb the best way to find out about new music was the 'zine' - heres a collection of issues from Maximumrocknroll, Suburban Voice, and Heartattack. Alas no Forced Exposure.

Brilliant workplace safety training video from Germany for Forklift drivers. Starts slow but the mayhem reaches quite a climax.

One for anyone that does technical support - The Book. Pretty sure I've linked this before . . .

A buzzword has been creeping into software development over the last few years - Agile.

For software development its all pretty good - the client gets what they want faster as usable code released more frequently takes precendence over traditional the Waterfall style model.

There is a spleen-worthy catch (or two) however -

Enterprise Architecture

If you're putting in point solutions or you already have a well established framework within which to fit your Agile-goodness then you're all set. If you haven't got the Architechture nailed (and I don't mean diagrams with lines connecting things up implying it'll all automagically fall into place) then you're going to be winging it.

At an operational level you'll have a bunch of systems and technologies going in with some questions about how it all hangs together - this kind of bottom up thinking will inevitably lead to a requirement to review whats just gone on and how it could be improved (which your integration partner will gladly charge you for when it should have all been planned out before anything went into production).

Ideally your Software Architect, Infrastructure Architect and Integration Partner would all sit around a table and plan how it'll all fit together before a single server is purchased. Throughout the process you need to involve the business itself in the process so that you actually build and deliver something that they'll actually use.

At an architecture level they need to determine what technologies will be used, the application framework will deliver, how it will scale, how it will move from dev to uat to prod, how easily other apps can be added into the framework, what training and resources are required, will applications be delivered externally, how will they be authenticated, if you have a CRM can the information be fed back into collaborative workspaces for the client or will there be islands of client metadata, how will these applications be managed and supported, will physical or virtual servers be used, what security will be in place, how will backup, recovery and dr occur, will systems be clustered or load-balanced etc etc.

Once all the pretty diagrams are in place they need to get to the nitty-gritty of how it will work in operation - what hardware to buy, what software, what network infrastructure, how the dev/uat/prod environments interact etc etc

Infrastructure Architecture

I reckon Agile & Infrastructure are two things that just don't go together - you can't make infrastructure up on the fly if you want anything more than basic services to support point-solutions. Infrastructure needs to be planned and documented to support whatever you want to build on top of it - once its in place then Project Managers, Analysts and Developers can be as Agile as they like.

Probably the single biggest factor (IMHO) in enabling an agile infrastructure would have to be Virtualisation. No more worrying about when and where hardware is going to come from and who will pay for it with the ability to provision new boxes in about 15 minutes flat. If it looks like you're heading down the Agile route convince the powers that be to invest and believe in a virtualised infrastructure.

It all seems pretty obvious that this stuff needs to be thought about but as an operations person if you start asking these questions you run the risk of not being 'Agile' and being perceived as the negative aspect of the development plan ('we can't deliver because the Systems team won't give us servers' or 'they won't give our integrator access to extend the Active Directory schema'). Of course Project Managers should ensure the 'big picture' is part of their plan but you'll often find PM's have tunnel-vision - they just want to get their project out the door and into the clients hands - how their application fits into the grand plan is out of scope of their project (its someone elses problem).

So plan and implement your foundations (see The Great Pyramid of Agile) before the buzzword-compliant methodology comes into play or you might find yourself playing perpetual catchup and being forced into a position of recreating the mistakes of the past by forcing in quick fixes.

A good guide us to place LUN's into Volumes grouped by similar Snapshot or Snapmirror regimes (as this functionality occurs at the Volume level). I think the techy term for grouping LUN's in this way is a 'Consistancy Group' - anything you need to get Snap'd together should be kept in the same Volume.

Another thing I picked up was that when allocating space for LUN's be sure to allocate twice the space you need to allow for Snapshots. This space requirement supercedes the default 20% allocated at the Volume level. For LUN based Snapshots the agent software on the host itself (eg SnapDrive for Windows or SnapDrive for Exchange) manages the Snapshot - it interacts with the SAN to ensure this happens properly but the SAN itself has no knowledge of whats inside the LUN.

What this means is that if every block in the LUN changes you need at least as much space again for the Snapshot or you'll get a disk-space error. Its unlikely this would occur - a situation in which it might would be a drive defragment which touched every block.