Mitch talks about the problems encountered when SysAdmins struggle to provision the infrastructure necessary to support developers - and I entirely see his point-of-view.

In my opinion, it is rare for an organisation that has SysAdmins that are already skilled up on the issues required to deploy new technologies when the development teams are cranking out brand new products. Most SysAdmins are busy keeping the existing infrastructure working properly and trying to optimise it - not out learning new technologies that aren't being used yet. That's not necessarily a fault of the IT staff (though I think it would be much better if more IT staff showed initiative and self-drive) but sometimes the culture of the organisation.

on the other hand, most developers are woefully equipped in terms of understanding the implications of what they are doing. The last thing an enterprise needs is rogue DHCP servers being setup that network build/provisioning systems, or rogue IIS boxes that can be compromised (NIMDA/Code Red anyone), or Exchange servers that become open relays. I've seen first hand, developers struggle for weeks to get Exchange, MOSS, DCs etc all functioning well together. And a typical solution to solving a problem is to open access to everyone, not follow best practices. In general developers seem to care about getting the thing working to spec - not worry to much about the side effects!

So how do we address the issue? In two ways I think.

1. Multiple Environments
Firstly we can create various environments within the organisation. The less impact that the environment has on production, the more control can be handed to developers and end users. In the most extreme case, you can have a completely segmented development environment, where developers can install whatever the want, configure it exactly how they want, and reconfigure it without needing to tell anyone else.

As we move closer to larger impacts on the production network, we need to increase the level of change control measures and the involvement of other parts of the business (namely the sys admins, the network guys, the security team and so on). And when we finally come to deploy the application into production, we have the full set of change control procedures (and division of responsibility) that applies to everyone else (it's not just developers that have to jump through hoops to get Active Directory changed - all the rest of the IT staff have to as well!). This change control process means that all relevant stakeholders know what is happening in the production environment, and that the production environment moves from one known state, to another known state.

2. Better Project Management (which is a prerequisite for agile IT)
good project managers know when to engage other parts of the IT organisation. This allows SysAdmins to research the product and its optimal configuration, work how how to provision the product, and even get a delegation tool in place to allow developers to manage select parts of the infrastructure. The project plan should look something like:

Good project management

Unfortunately, in a lot of cases, it seems to look like this:

Bad project management

And that type of poor project planning results in low agility IT.