"Agile" is an overloaded term in this context. At this point in time, it has no real meaning in the systems administration world; at least, not in the way that all or most software engineers have the same basic idea of what philosophies, processes and workflows underpin all methods of agile software development (Scrum, XP, etc.). Agile methods emerged in defiance of the waterfall methodology, the bureaucratic and over-structured approach to software development that was most popular at that time. Does Agile systems administration take the same stance towards the disciplines promoted by ITIL, COBIT and other IT frameworks? Why or why not? How different are the requirements of systems administration/engineering from those of development, really, and beyond co-opting a word with meaning as a buzzword, how can we preserve the philosophy of "agile" development in practice as well as principle?

In software development, Agile focuses heavily on correctness and testability, relying heavily on the deployment of unit tests. Shouldn't agile systems administration be able to verify the correctness of deployed packages, by utilizing the checksum verification feature of most modern package managers? Shouldn't we be able to trivially verify that all of the dependencies of a piece of software are installed before that piece of software gets installed, by relying on the tools the package manager already has and uses well? Agile is about more than just moving quickly and adapting to changing requirements -- the core prerequisite, possibly the single most defining characteristic of Agile development, is that while the requirements change, while you refactor a software system, you can verify the correctness of the component parts. Verifying correctness doesn't slow you down, but is what enables you to move faster, like brakes on a very fast car, to paraphrase Behr, Kim and Spafford.

The right answer, and the correct approach, in my opinion, hinges on the fact that configuration management systems and packaging systems are not in competition with each other; at least, not as long as the packaging system is properly designed and conceptually separates application data from configuration data. After all, we don't call it an "application management system" or a "software management system," and that's for a reason -- we're Unix guys who recognize that if you want a God Tool that does everything at once, you fire up a C compiler. (Or, alternatively, you insert a 25-year-old Emacs joke here.)

The configuration management system, or at least the DSL in which you write your configuration management information, shouldn't have to know anything about how to install a piece of software onto a given operating system. That's the package manager's job. At most, it should have to specify what the package is, and possibly where to find it. The only files the configuration management system should conceptually have any ownership over are, well, configurations.

Awesome, commented on the wrong article. :)