A mutable Puppet show Configuration management is essential for Mutable without tears

The Mutable business, the evolving business in a constant state of change, is going to be high-risk – unless it is founded in a basis of “good governance”. If you change things quickly you risk breaking things, unless you know where everything is, who is looking after it, what state it is in and what part of the business it impacts.

That means “Configuration Management” – CM – and it has to be agile CM, or it will impact your ability to change as and when the business needs you to. CM is mostly a process thing, but choosing the right CM automation technology can help to institutionalise good process, once you’ve worked out what process you need. And, always remember that CM should be about managing everything essential to delivering a business outcome – it extends beyond mere technology (there’s an introduction to CM here).

One CM tool I particularly like is Puppet, partly because it is Open Source, so there is low cost of entry. It is easier to institutionalise good process if you can afford to start small, before you are big enough to make not having it a disaster, and “grow with success”.

Mainly, however, I like Puppet because it is declarative – you say What configuration you need to deliver business outcomes, rather than How your systems should be configured, using a model-driven CM approach. This should make it easier for the business to buy into CM and without effective business buy-in, I don’t think CM can ever be reliable, up-to-date and agile enough to support a Mutable business.

Puppet seems to be expanding its offering at the moment, at one end integrating more with DevOps and supporting a Command Line Interface and Puppet Tasks as well as its Declarative interface. I feel this CLI feature is useful; but it needs to be used with care, as the Declaritive approach better abstracts the business from its technology.

At the other end, it has introduced Puppet Discovery, which helps you to discover what is actually out there and helps you to analyse the gaps between the model of what you think you have and the (often scary) actuality. This contributes to practical governance and compliance, still important even in the Mutable business. According to Puppet’s Chief Technical Strategist Nigel Kersten, it is blurring the lines between the traditional development and administrative domains.

I feel, however, that I must re-iterate that CM process matters more than CM tools – and you need to get your process right before choosing tools. There are other CM tools – Chef and Ansible are good Open Source tools, for example (see the blog here). Which tool is best for you depends on the CM process that suits you – don’t choose the tool before you know what you need and remember the old Einstein quote paraphrased as “Everything should be made as simple as possible, but no simpler.” CM is sometimes misunderstood as simple code version control and oversimplified CM, especially applied just to code, won’t support a Mutable business.

David Norfolk

My current main client is Bloor Research International, where I am Practice Leader with responsibility for Development and Governance. I am also Executive Editor (on a freelance basis) for Croner's IT Policy and Procedures (a part-work on IT policies). I am also on the committee of the BCS Configuration Management Specialist Group (BCS-CMSG). I became Associate Editor with The Register online magazine – a courtesy title as I write on a freelance basis – in 2005. Register Developer, a spin-off title, started at the end of 2005, and I was launch editor for this (with Martin Banks). I helped plan, document and photograph the CMMI Made Practical conference at the IoD, London in 2005 (http://ww.cmminews.com). I have also written many research reports including one on IT Governance for Thorogood. I was freelance Co-Editor (and part owner) of Application Development Advisor (a magazine, www.appdevadvisor.co.uk, now defunct) for several years. Before I became a journalist in 1992, I worked for Swiss Bank Corporation (SBC). At various times I was responsible for Systems Development Method for the London operation, the Technical Risk Management framework in Internal Control, and was Network Manager for Corporate group. I carried out a major risk evaluation for PC systems connecting across the Bank’s perimeter to external systems and prioritised major security issues for resolution by the Bank’s top management in London. I also formulated a Security Policy for London Branch and designed a secure NetWare network for the Personnel Dept. Before 1988 I was an Advisory Systems Engineer in Bank of America, Croydon in database administration (DBA). on COBOL-based IMS business systems. Before 1982, I worked in the Australian Public Service, first as a DBA in the Dept of Health (responsible for IMS mainframe systems) and latterly as a Senior Rserach Officer 2 in the Bureau of Transport Economics. Specialties: I have the ability to extract the essence of significant technical developments and present it for general consumption, at various levels, without compromising the underlying technical truth.

Have Your Say: