IT Automation Curator – Good for techies, good for business, good for DevOps

Recently my thoughts have been going back to a concept I like in the seminal IT operations book, The Visible Ops Handbook (By Gene Kim, Kevin Behr, and George Spafford). I have been doing a lot of thinking about how Lean, DevOps, Agile, etc. are changing IT culture, or at least pressing for change. Properly leveraged automation is a big part of that change process – which makes me think of the passage in Visible Ops where the authors discuss changing the behavior of senior IT staff:

“Their mastery of configurations continually increases while they integrate it into documented and repeatable processes. We jokingly refer to this phenomenon as ‘turning firefighters into curators’ […]”*

As a former IT techie myself, I get the need to challenge oneself in the often routine and monotonous world of IT. Personally, I think that is a lot of the grass-roots impetus behind the DevOps movement, and the adoption of open-source automation tools. Creating automation is a way of turning the mind-numblingly mundane into something exciting and intellectually challenging. So far so good. Boredom leads to sinking morale and productivity – poor morale is bad for business.

So, what’s not to like? In short, it goes back to focus and sustainability. No, I’m not talking green-energy windmills. How do you sustain and focus the efforts of these budding automation aficionados? Left to their own devices, they will likely create lots of useful, but narrowly directed scripts, packages, etc. All of these will be focused on the problems they face on a daily basis. For the problems outside of the automation guru’s gaze – those problems will most likely remain unsolved.

So, this is where the idea from Visible Ops comes to the rescue. The answer is that we pull these gurus out of their day-to-day grind in the IT trenches,and make them automation curators. Now, I know that many of you hear curator and think of a older man in a tweed jacket, peering over horn rimmed glasses, waxing rhapsodic about the various manufacturer stamps of 18th American chamber pots. So, as interesting as early american port-a-potties may be, let’s look at the definition of curator:

curator – one who has the care and superintendence of something (Marriam-Webster Dictionary)

Clearly tweed is not mentioned. In all seriousness, museum curators do much more than merely talk about old things. Considering the Smithsonian’s own description, curators:

  • Acquire new items for the collection
  • Research the collection
  • Display the collection
  • Maintain the collection

So, if we work off the Smithsonian’s “model”, I suggest that an IT Automation Curators would:

  • Collect existing automation, and then Catalog it where others can find it
  • Develop new automation based on requirements from IT
  • Train others on how to use the automated processes
  • Maintain the existing automation

This kind of role is exactly what I missed someone had offered me early in my career. I would have jumped at it. It would have been a great new challenge for me, I would have been creating value for the business, and IT would have been more efficient. And this isn’t really a new idea. Software developers have long needed to share code snippets and concepts with each other, and they defined the interfaces between code as well. The trick here is that Automation Curator needs to take an active role in both building the best automation and also in promoting the proper use of automation in IT.

One last comment. We might ask if this would be better classified as an Automation Librarian. I think it is good question. At the end of the day, I think having the existence of the position is more important than what you call it. However, in my mind the concept of curator leans more towards the acquisition, development, and training part. The words Library and Librarian in IT seem to lean more towards the maintenance and storage part of the equation (notwithstanding what traditional librarians actually do). Curator is also a cool word.

So, why aren’t more IT shops doing this? What do you think?

This is the first part of a multi-part series. Check out the other parts:

* Kim, Gene; George Spafford; Kevin Behr (2005-06-15). The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps (Kindle Locations 917-919). IT Process Institute, Inc.. Kindle Edition.


13 thoughts on “IT Automation Curator – Good for techies, good for business, good for DevOps

  1. Coming from manufactring Ops and recently moving to doing software dev, I see some parallels to this idea with certain Lean tools and roles; in particular kaizen events and coaches. You mentiond devs creating their own tools to automate processes and it seems this dovetails neatly with Lean concepts of treating frontline employees as experts and leveraging that expertise via kaizen events to improve the process. I also see some parallels between a coach and a curator. There are, of course, obvious differences in manufacturing widgets and developing software, but there are clearly some tools and ideas that are transferable.

    • Great comment, Mark. I agree 100% that Lean has a lot to teach us in IT. If fact I just blogged on it earlier this week on the BMC DevOps Community. I really like the point you bring out about empowering frontline employees and treating them as experts. In IT we seem to either treat proactive people as risks to be controlled and we give them full reign with little guidance or control. Promoting your senior engineers as coaches is a great way to bring some order to potential chaos without smothering the creative energies of the people in the trenches.

      Keep the comments coming!!

    • I was a syadmin/systems architect for years, so I think I understand the perspective. The problem with that view is three-fold:
      1) It assumes that there is no difference between more junior and more senior sysadmins in terms of experience and effectiveness. John Allspaw’s post “On Being a Senior Engineer” backs that up. It is important for the most experienced and talent experts on the team to brings others skills up, and provide best practices.
      2) That line of thinking also assumes that the sysadmin understands the full stack of software, from OS to App. In more complex environments, I just don’t think that is the case. By necessity, most engineers specialize in something, and that is fine. My argument is just that we need engineers that specialize in automation and process. They can work with the subject matter experts of each layer to automate their expertise in the best possible way.
      3) I firmly believe that is important to establish some standards around automation. I have seen a lot of environments where automation is determined by whatever the fancy is of the latest sysadmin to touch the system. That is a recipe for significant downtime when that sysadmin moves on, goes on vacation, or gets hit by the proverbial bus – and nobody knows how its works.

      Part of this is coming from my own experience. As a former systems engineer that enjoyed automating things, I wish I had been given an opportunity like this, instead of being forced to blaze my own trail. In the end I became an “Automation Curator”, but only after a lot of unnecessary pushback and wasted time.

      Now, that said, in simpler, smaller environments, with the best engineers – maybe you won’t need an Automation “Guy”. And that’s fine. I just don’t believe that is the right answer for most IT shops.

  2. Hi,
    Awesome post. I have been thinking of automation curator idea, not in the exact same way. In the past six months I have been using Ansible as our automation, provisioning and adhoc command tool. Its very easy to use and easy to get up and running. But one thing that struck me is that it is so easy for anyone to understand what is happening when using Ansible. The concept of a playbook has a group of tasks. (Sorry if this is sounding like an advert for Ansible), but these playbooks make documenting setups and common tasks easy. As a Director of IT I look to tools that promote easy automation, documentation, and best practices. I try to design networks and setups with the “if I disappear” rule in mind. Meaning another sys admin of lesser knowledge should be able to look at my work and understand how why we did something in a certain way.

    • Thanks for the comment, James. I think you have the right perspective. I used to have a more morbid name for that – the “if I get hit by a bus” rule. I think there is a natural inclination to think that you make yourself indispensable and important through designing automation only you can understand. The irony is that following that path means you can never move on to other challenges. I learned that lesson the hard way :).

      This approach means more work up front, but the rewards are greater over the long term. My hope is that by creating automation curators and best practices, it will significantly reduce the up front cost of doing things this way.

      • My phrase for that is ‘If I win the lottery’ which is a little more positive. It also brings up a leadership principle that is worth mentioning. A manager’s goal should be to make themselves dispensable, otherwise, how can you progress in your career and how can your reports progress in thiers?

      • Good points. I would rather win the lottery than be hit by a bus. I think your point about management is really applicable. It requires thinking long term, and it isn’t always easy. It means putting your ego aside for the short term for long term gain. Making other people successful will always bounce back positively on you – and you feel better, too :).

  3. Pingback: IT Automation Curator for DevOps – Part 3 – Developing Automation with Lean Methodology | Newtonian Nuggets

  4. Pingback: Training others in the dark arts of DevOps Automation | Newtonian Nuggets

  5. Pingback: Kaizen and the Art of DevOps Automation Maintenance | Newtonian Nuggets

  6. Pingback: IT Automation Curator – Good for techies, good for business, good for DevOps | I can explain it to you, but I can't understand it for you. |

  7. Pingback: 3 Reasons why DevOps isn’t changing IT faster | Newtonian Nuggets

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s