Users want Conversations, not Monologues – How does that change DevOps and APM?

My blog last week about the new reign of the end-user has started some interesting discussions, both online and off. In particular, I had a Google Hangout with some of my colleagues, and we got on to topic of end-user monitoring and DevOps. Chris Dancy (@servicesphere) riffed off of my comment about the low switching costs of moving from one web app to another, and talked about empowering users. Users (That is ME, YOU, US) are no longer dependent on their business’ IT department, their ISP, or techie neighbor to get what they need from technology. If we don’t get what we want from our provider, we will do it ourselves, or got to a “competitor”. The “walls” to personal innovation just aren’t there anymore.

I made the comment that what we really need is “End User Activity Monitoring”, which my good friend Dave Williams has talked about extensively. The basic idea is that, to give the user the experience they really want, we need to be able to measure that experience no matter where they are or what device they are using. We can extend that “monitoring” in a more human way by asking “questions” as opposed to just monitoring bits and bytes. Jason Frye (@fryfrye) responded to this in the Google Hangout with the great observation that we can take it one step further and show them their own data. The provider can be proactive and let the user know that there are problems, and that a solution is being worked.

So, as I was thinking about this, it really came together with one idea. Humans want to converse, not be talked at. I was amazed to learn that my 18-month learns language not simply by hearing it, but by listening to, and watching, a human speak it. She want to talk WITH me, even before she can actually speak. And I think it goes to technology as well. I want my world to respond to me. My experience with certain brands (like Amazon.com and Apple) has become almost familial (which makes Kindle and iPad seem like a slightly awkward argument over dinner). When Amazon asks for my review, I feel included. Even though I am annoyed when a shipment is delayed – telling me somehow makes it less annoying. Even with consumer gadgets, it applies. I love my Garmin watch when I run, not because I really do anything with all that GPS data. I just love the second by second feedback on my performance.

So, what does this all have to do with DevOps and App Performance Management (APM)? Well, I think it is very easy to thinking of the relationship with the “user” as a one-way relationship. Even when trying to make the user happy, it is more a push, then persuasion. So, what is DevOps tools could take not only live APM data on the measurement of end-user performance, but also more subjective data from the user, into account. What if the application proactively warns you of trouble, and makes suggestions. What if the application actually suggests other things you might like (like other applications). I think this concept is pretty well understood in retail (like with Amazon.com or Zappos.com), but I am not sure that it has really made its way into the thought behind DevOps and APM. The Social IT revolution is no less powerful than the DevOps movement, and it is in our (IT professionals) best interest to bring them together. User not only need a relationship with the help desk – they need relationships with IT operations staff, Developers, and all the other powers behind the curtains. Clearly some internet companies have mastered parts of this, but I would really like to see this interactive empowering of the end-user to work its deeper in IT. We are ALL users after all, aren’t we? So we should understand how they feel.

Advertisements

The Mythical Application Owner – And Why They Matter to DevOps

I have been on both the customer and the vendor side of Application Management over the last decade. So, I was surprised how much trouble my team and I had really defining the Application Owner as a sales target. With our collective backgrounds, I expected it to be a breeze. Of course the CxOs, VP Operations, and others are well know entities. So why is the application owner so difficult to find? One reason is because the definitions are all over the place.

For example, one definition on the IT Law Wiki says:

An application owner is the individual or group with the responsibility to ensure that the program or programs, which make up the application, accomplish the specified objective or set of user requirements established for that application, including appropriate security safeguards.

Snore… I could be in charge of Microsoft Office for my company and fit that technically focused, but inherently logical, definition. NIST has a similarly technically oriented definition. Now in all seriousness, we can see that part of the problem is that I really mean a business application owner, not a technical owner. In that vein, a definition much more to my liking can be found on this blog entry from Nick Spanos on his Lean IT blog. In the spirit of lean methodology, he brings in business/customer outcomes, business processes, etc.

So, who cares? I think anyone who cares about DevOps should care. As DevOps expands from a grassroots movement to a business-changing phenomenon, it needs to continue to develop thought patterns that appeal to those footing the bill. This is where so much good thinking in IT falls down – the inability to articulate the value to the business. That said, I don’t think it has to be complicated. I see two over-riding characteristics:

They live, eat, and breathe application revenue

For every revenue-generating application out there, there is someone being measured on that revenue. For a small company, that might be the CEO. For a Fortune 500 company, there could be dozens of applications, each with an owner. Regardless of industry, somebody goes to sleep at night worrying about whether whatever.com is measuring up to expectations.

They care (or should care) about customer value

Customers pay the bills, so worrying about revenue means obsessing about customers. I think that one of the common themes for companies successfully implementing DevOps is the over-riding need to deliver customer value. This is coincidently very much in line with lean methodology – which is why lean and DevOps are so good together. An application that is always in danger of losing customers and competitiveness is fertile ground for DevOps. If your application isn’t in a competitive space, why would you even bother?!

Pretty much everything else is going to be different by industry. An application owner at SuperCoolStartup dot com will likely be very different than the app owner at BigRetail dot com or the MBA educated person running SomethingOrOtherFinancial dot com. What they should have in common in the commitment to increasing revenue by increasing customer value.

Now, one caveat. Not every application has revenue. I would argue that the lack of the profit imperative makes a wrenching change like DevOps much more difficult, but you can insert “mission” or “fund raising” for most of these points.

So, why does this matter? DevOps practitioners, and IT organizations in general, have an unprecedented opportunity to make IT matter to the business more than it ever has before. IT can become an enabler for revenue, rather than a pure cost center. However, to do that, they need to learn to express the value of DevOps in revenue and customer-focused terms, and begin to make the case directly to the application owner. Over time, I think the pendulum of power is swinging from the CIO and VP operations to the application owners. So, IT needs to make some new friends!

IT has been deposed – Long Live King User

Most of us (if you are reading this, you are a self-selected subset) are fascinated with trends in technology and IT, which is great. The problem is that, with all the activity and progress going, it is easy to miss the forest for the trees. I think it is really instructive to take a step back sometimes and ask the big questions. Like this one – Are some of the major technology trends of our day – Cloud, DevOps, App Performance Mgmt (APM), Smart Phone and Tablets, etc. – completely separate trends, or all part of a larger narrative? I don’t ask that to reduce the power of those trends – I just think that it is worth asking if something more seismic is going on.

So, to answer my own annoyingly rhetorical question – I think there is a bigger trend. The user, in whatever context in which he, or she, operates, wields more power today than ever before. Entire industries are being built for the sole purposes of making users happy – or least making them think they are happy. And for those verticals that aren’t so obviously pandering, any competitor that ignores the experience of their end-users is bound to crash and burn. And I am not just talking about reverse voyeurism of over-sharing Facebook users and the beauty of Apple products. Staid and complacent industries everywhere are being shaken to their core as users demand the same level of experience in the business world that they experience when interacting with applications in their personal lives. So, here are a few of the trends I follow, and how I think this “mega-trend” ties them all in.

DevOps and Agile Development

One of the main purposes of Agile Development is delivering customer value. The first of the twelve principles of the Agile Manifesto is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software“. Agile development puts the customer on a pedestal, and works to make the customer satisfied. Why? Because the customer pays the bills, that’s why. And not only do they pay the bills, in the world of the Internet users can quickly take their business elsewhere when they are not satisfied. At the end of the day, on the major objectives DevOpsis to push this maniacal focus on delivering customer value all the way into IT operations – where it is has been sorely lacking.

Application Operations and Application Performance Management (APM)

As the less hip and more staid cousin of DevOps, APM has an even easier case to make about the primacy of the end-user. In the past, APM has been primarily about bubbling up complex application performance data from a complex application architecture, and trying to make sense of it. While that kind of deep-dive analysis is important, it can be misleading and distracting. Recent trends in APM, particularly around those same Internet applications driving the DevOps movement, are focusing more and more on the end user. With the “switching costs” so low today, users will leave for the competitor’s site if there is on average a 250 ms or more difference in response time. That is 1/4 of one second. In only 2009, a study Forrester put the acceptable wait time at 2 seconds. Today, in the case of high-performance sites like Google, even 400 ms is too long. Bottom line, if your customers are receiving sub-par response times, you are probably losing them to competitors. It really is that simple. And if an IT department isn’t measuring end-user performance, they are essentially allow their company to stumble blind into a pool of sharks/end-users. Good job IT.

The Business User’s long sojourn in the wilderness of crappy IT support is over

This trend is probably the most disturbing to an IT department and most exhilarating for any IT user. Business IT users are no longer satisfied with flimsy laptops made by do-it-cheaply hardware manufacturers and web applications with appalling user interfaces, seemingly built for Windows 3.1. Apple, Google, Facebook, and others have taught them that technology can beautiful, easy to use, secure, AND effective. The IT departments’ insistence that the need for advanced functionality and security necessitates technology that induces suicidal thoughts and dulls the mind into oblivion, no longer stands. IT users want to be free. They want to bring their iPad, Android phone, and Mac Book to work. Most IT departments don’t really like the stuff they peddle anyway. Now they just need vendors that actually deliver them products that don’t make their users scream in frustration.

Social Media is the tool of User Domination

And how does King or Queen User rule? Through social collaboration tools. Social media is not just about showing pictures of your cute toddler (guilty…) or trying to remove tags from embarrassing photos anymore. Social media is about capturing the best ideas from the people who stand to benefit the most from their realization. It is about encouraging healthy competition and ego-boosting for the sake of information sharing and content creation. And, most of all, it is the platform of user rule – Social IT. And it can’t be ignored. Countries creating “fake internets” and companies with draconian IT policies won’t stop the change. Users always find a way to flaunt the rules, like they have since the dawn of time.

So, is this a good thing? I believe that it is. I think the the essential lesson here is that business has always been about delivering value for the customer. The difference now is that customers actually know how much value companies, organizations, and countries are delivering. Keeping “the man”, the president, and the boss accountable. That is definitely a good thing.

Kaizen and the Art of DevOps Automation Maintenance

And now we come to the most “boring” part. Right? Maintenance. The death of joy for the innovator. Or is it? I don’t think so. Continuous innovation is at the core of DevOps and Lean methodology. Maintenance is essential to keeping the spirit of DevOps strong, and automation that isn’t improving will grow stale and useless.

So, let’s review the IT Automation Curator’s job description on last time:

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

Going back to Lean methodology, we can look to the idea of Continual Improvement or Kaizen. There are 3 main areas from Masaaki Imai‘s 1986 book Kaizen: The Key to Japan’s Competitive Success.

  • Reflection of processes. (Feedback)
  • Identification, reduction, and elimination of suboptimal processes. (Efficiency)
  • Incremental, continual steps rather than giant leaps. (Evolution)

Use Metrics and Reporting for Feedback

How can you improve if you don’t know how far you’ve come and how well you are doing? That’s like going on a diet without ever weighing yourself or even looking in the mirror. Healthy weight loss involves such small changes every week that it would discouraged if you didn’t look at changes over the long term (I speak from experience). So, why do so few companies and automation vendors include metrics and reporting on automation efficiency?! The whole point of implementing automation is to reduce waste, reduce costs, and increase velocity. But you have no context for understand if you have succeeded if you don’t have metrics and reporting (I talked about this in a previous post).

Ruthlessly eliminate sub-optimal processes

The whole point of this process is get rid of wasted effort and time – muda. The hardpart here is that once you agree to continually improve your automated processes, you have to be ruthless in your evaluation of their efficiency. That means there are no sacred cows. Just because somebody smart and dedicated invested hours of their life into creating something, doesn’t mean it can’t be improved or scrapped entirely. The whole team has to be dedicated to, and incentivized towards, efficiency and continuous improvement. This point is important – these kind of improvements come from the grassroots – not the top. If the people in the trenches aren’t bought into continual improvement, it won’t work.

Baby Steps, not Leaps of Faith

I know the hardest part of this approach for me is the gradualism. I like to grandiloquently solve grandiose problems with lofty and visionary solutions. The problem is that most of those involve large amounts of kool-aid, and they are never finished. The truly mature IT organization has to keep their eye on the goals of the business, and relentlessly reduce muda – step by tortuous step. We can refer back to the weight loss analogy. You lose weight through all of the small victories – Do I really need that donut? One serving is good enough. But bringing us back to our first point – small victories only show up as victories when you can measure your long term progress. Otherwise it looks like tentative, timid, risk-adverse behavior.

And so, we reach the last chapter of my IT Automation Curator series. It has been a lot of fun writing it, and I hope that you enjoyed it as well. I am looking forward to continuing to explore how the proven methods of lean and agile can be applied to DevOps and Operations overall.

Training others in the dark arts of DevOps Automation

If you are the Automation hero, why would you EVER share that stage? You are basically reducing your value to the organization by sharing your secrets. Right? Wrong! You are actually doing yourself a lot of harm, as I discussed in the the first blog post. How can you move on to other exciting challenges if you have to maintain your work of automation genius?

That is why the the IT Automation Curator’s job description has training as a core requirement:

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

I had a great comment from jamesmarcus in the first blog post. Here is what he said:

“As a Director of IT I look to tools that promote easy automation, documentation, andbest 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”.

I think this is a great perspective at the core of why I included training in my job description. Very few programmers, sysadmins, and other IT techies enjoy documenting their work. I don’t either – when it is after the fact. It is so mind-numbing to document your automation after you are already done and want to move on. So, that brings us to our first post.

Build your Automation to be well-documented and re-usuable

While performing amazing feats of scripting judo can impress your colleagues and get you kudos online, it is not a good long-term objective. One thing I learned early as a programmer is that creating incredibly efficient and elegant code seemed great, but it was really bad if even I couldn’t figure out what I had done a year later. That all comes down to great comments while you are writing the code. I know this may seem basic, but I have seen too many IT organizations with automation scripts, packages, etc. that no-one understands anymore. This is essentially a guarantee that the automation in question will be left alone to become outdated, brittle, and even “dangerous”. And if you are the only one that understands it, then it is your burden to bear.

So, basic to our train function of the IT Automation curator. How can you possible train people if your automation is over-complicated, un-documented, and impenetrable to mere mortals? Only with difficulty, and no one (especially you) will enjoy the experience. By documenting your automation very well as you write it, and building it to be as straightforward and simple as possible, you increase your chance of handing it off successfully. Writing well-documented and straight-forward automation has to be part of your process – bottom line.

Find automation disciples, and train them in the dark arts

While I see no reason why you can’t “teach” a class on automation as part of this role, I don’t think that is optimal, or even desirable for most people (stage fright anyone?). I have always envisioned a much more personal approach to automation training. Not every sysadmin, administrator, or IT techie extraordinaire will have an aptitude for, or interest in, designing automation. The right person has a somewhat rare combination of programming know-how, patience, troubleshooting skills, and IT systems knowledge. Obviously, everyone will use the automation, but only a few will write it.

The IT Automation Curator should be a mature, senior IT operator that has an eye for spotting talent. Like Mr. Miyagi in Karate Kid, you can watch for the young IT admin with lots of promise and fire in their belly, but unable to conquer the IT problems with their lousy karate skills. In all seriousness, I think mentoring promising candidates on automation best practices is more enjoyable and effective than the typical shotgun approach. The best part is that you can let the young upstart take care of the boring automation bits, while you save the best for yourself!

So, in summary:

  1. You can’t pass on automation that impenetrable to anyone but yourself
  2. One-on-one mentoring is a much more effective way to pass on your automation skills and knowledge

So, here is a parting challenge for all of you out there that actually remember Karate Kid. What might the IT Automation equivalent be of Mr. Myagi’s “catch a fly with chopsticks” trick?

Developing Automation with Lean Methodology

So, now we are on what I consider the most fun part of the IT Automation Curator’s job description ( see the first blog post ) – developing new automation. Let’s first review the job description as I outlined it:

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

There is lots of great technical material out there about creating automation, and I won’t try to duplicate it here. And I also won’t push a particular toolset, though I have my opinions, of course. I am convinced that most automation project fail, not because of problems with the toolset, but rather due to problems with the approach. That doesn’t mean that one tool isn’t better than another, quite the contrary. The difference is just how successful can you be when you do it right.

To Automate or not to Automate – that is the question.

I think choosing what to automate is much more important to how you choose to achieve the automation. The best model we have for that, in my opinion, is Lean Methodology, and Lean Software Development, in particular. The Poppendiecks, creators of Lean Software Development, have their first principle as Optimize the Whole. The whole point of this step is to eliminate waste, known as muda in Lean methodology. Muda is “anything which does not provide customer value”. This is such a simple, yet revolutionary, concept. What if every sysadmin asked himself whether that script he was working on added customer value? Would they even know how to answer the question.

So, how do you answer that question? You look at the whole, end-to-end, process. This means no silos, no team-centric thinking, no “that isn’t my job”. What does it take to deliver a service to the end user/customer, and where are we wasting time and resources? In Lean Methodology you figure this out by drawing a value stream map. In the context of manufacturing, the source of lean methodology, it meant going from factory to factory, supplier to supplier, and putting together the complete picture of how a product is built and delivered.

So, what does that mean to our Automation Curator? Typically lean, or agile, software development stops at the delivering of the product to IT Operations. In the spirit of DevOps, that needs to stop. IT organizations need to start looking at the delivery of a service to a customer from requirements all the way through to production. That is the only context where it makes any sense to uncover muda. If you view IT Operations in isolation, you could very well create a highly efficient IT operation that doesn’t good services.

The IT Automation Curator has to focus on the automation projects that provide value to the customer – delivering new applications and features faster, restores services faster, provides better customer experience, etc.

What does success look like?

Once you have automated a process, how do you even know that you have achieved your goal of eliminating waste? That where measurement and reporting come in. If you have no way of measuring the effects of your hard work, how do you even know if you have been successful? You don’t. That means part of developing any automation has to be about measuring the impact on the customer. For example, you just automated the full-stack build of an application from scratch. How much more quickly can you deliver updated applications, or recover from problems? So, you have automated the application release process. Did that reduce downtime and error during new releases?

Once you have those reports – advertise them. Don’t be shy about showing how you are increasing value for the end customer. So many IT departments have been forced to show value by how much they can cut out of their budget. How much more would the business appreciate an IT department that demonstrably increases value for the customer?

I think this approach is so much more effective for determining what to automate and how. This singular customer and business focus is bound to make the IT Automation Curator a valuable member of the team. A lot more valuable than the “IT Hero” that corrects a preventable problem with heroic effort. I am also hoping to see this result-focused approach take over from the tools-focused approach so prevalent in DevOps today. If DevOps is to be relevant for more than just a few years, it must encourage behavior that adds value to the customer. Why? Because the customer is King!

IT Automation Curator for DevOps – Part 2 – Collect and Catalog

This topic is far too interesting and deep to cover in just one blog post. So, I am going to split the discussion into a few sections. I’ll use my proposed “job description” for an IT Automation Curator as a starting point:

  • 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 first step of collect and catalog is where I have seen many automation efforts stumble. The natural inclination of most techies (myself included) is to jump right into developing automation, no matter what is in place. As I learned the hard way, that is a bad idea. So, I will give a few reasons why this step is important:

Reason #1: If you don’t know about all the automation in place, you don’t really understand how your data center is operating

It’s great that you developed that new automated process that auto-magically deploys a set of configurations for you. Are you sure that other scripts or tools won’t change it or corrupt it? Most IT teams have scripts strewn all over the place – some well known , some the detritus of sysadmins past. They may have been scheduled centrally or on individual servers. This is very hard to get a grip on. There are a few tools out there, but it is hard to ensure that you have found all automation spread over all the systems. This is just another reason why you need to control access and even re-build some servers from scratch (hopefully in an automated way).

Most IT operations teams also have multiple automation tools in play. Each silo-ed team has their preferred tool, which they guard jealously. Overall, this is not a good approach. The more tools you have, the harder it is to standardize automation and create efficient end-to-end processes. At a minimum, all of these tools need to documented and managed centrally.

Reason #2: Don’t duplicate work and ignore experience

A lot of the automation in place may not be optimal, but it was most likely built to solve the same problems you will need to solve later. Tossing it out, or just ignoring it, is essentially disregarding the combined experience of the IT team. Even if you rebuild it in a better tool, and in a more efficient way – the lessons learned will be valuable.

There is also an important less here about prioritization. Just because you can make an automated process more elegant or more efficient, doesn’t mean you should. More often than not you will have no end of automation projects to look at. Why spend your time on what already works? What is important is to apply automation judiciously, where it provides the most value for the business.

Reason #3: More sharing will always lead to better results

Fostering a culture of sharing automation, essentially an open-source culture, will ensure that everyone has access to the best work on offer, that they don’t re-invent the wheel, and it will allow for continual improvement. That last point is crucial. The idea is not for the automation curator to control all the automation per se. They should be catalysts for making better automation, whether they do it or not. So, it is important to leave one’s ego at the door, and admit that your automation becomes better when you let others critique it and improve on it.

Bottom line, having a central place to share and continually improve automation is essential. This will most likely affect your choice of automation platforms as well. If you can’t share and improve, then you will be hobbling yourselves.

So, how do you do this in your own environment? Do you have ideas about the best way to go about it? Any success stories?

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.