Contact ITInvolve

Archive for December, 2013

DevOps Needs a Place to Work

Friday, December 13th, 2013

Because of the roots of DevOps within the Agile Software Development movement, there is a strong theme of “individuals and interactions over processes and tools” within the DevOps community (see for more). To a significant extent, this attitude has been taken to mean tools are not really necessary and everyone can or should roll their own approach so long as they follow DevOps principles (for a good DevOps primer, check out the Wikipedia page here and the dev2ops blog here).

More recently, the DevOps community has begun to embrace a variety of automation and scripting tools, notably companies like Puppet Labs and Chef, because DevOps practitioners have recognized that doing everything by hand is both tedious and highly prone to error. That has led to a new term “infrastructure as code” (Dmitriy Samovskiy has a quick primer on his blog here.) But beyond automation (and, to a lesser extent, monitoring tools), the DevOps community hasn’t fully embraced the need for other types of tools to aid in DevOps work.

What’s more, despite this evolution around the need for automation tools, and the recognition that individuals and interactions are key, there are still a lot of walls in most organizations that impede the DevOps vision for continuous delivery of new applications. Quoting from dev2ops:

Development-centric folks tend to come from a mindset where change is the thing that they are paid to accomplish. The business depends on them to respond to changing needs. Because of this relationship, they are often incentivized to create as much change as possible.

Operations folks tend to come from a mindset where change is the enemy.  The business depends on them to keep the lights on and deliver the services that make the business money today. Operations is motivated to resist change as it undermines stability and reliability.

Both development and operations fundamentally see the world, and their respective roles in it, differently. Each believe [sic] that they are doing the right thing for the business… and in isolation they are both correct!

Adding to the Wall of Confusion is the all too common mismatch in development and operations tooling. Take a look at the popular tools that developers request and use on a daily basis. Then take a look at the popular tools that systems administrators request and use on a daily basis. With a few notable exceptions, like bug trackers and maybe SCM, it’s doubtful you’ll see much interest in using each others [sic] tools or significant integration between them. Even if there is some overlap in types of tools, often the implementations will be different in each group.

Nowhere is the Wall of Confusion more obvious than when it comes time for application changes to be pushed from development [to] operations. Some organizations will call it a “release” some call it a “deployment”, but one thing they can all agree on is that trouble is likely to ensue. 

Again, despite the recognition that some level of automation tooling for DevOps is needed, and despite the fact that individuals and interactions are seen as critical, the DevOps community hasn’t really developed a strong opinion on exactly how Dev and Ops should work together and precisely where they should do so.

Julie Craig of Enterprise Management Associates, describes the need pretty well in a recent whitepaper:

“…their tools must interoperate at some level to provide a foundation for collaborative support and Continuous Delivery.”

“DevOps-focused toolsets provide a common language that bridges skills, technical language, and personalities. In other words, they enable diverse personnel to seamlessly collaborate.”

“…tools must interoperate to support seamless collaboration across stages…data must also be shared as software moves from one stage to the next.”

Now, it’s all well and good to talk about the need for integration across tools and more collaboration, but where and how should Dev and Ops functions actually go to get work done together. Where and how do they best exchange information and knowledge about releases that are in process, engage with business stakeholders to validate business requirements, notify stakeholders of changes to functional specs and operational requirements? Where do they go to have an accurate understanding of the full stack required for deployment, to understand disparities and drift between pre-production and production environments, and collaborate together on deployment plans and potential risks that may exist and should be mitigated?

These are just a few examples of the DevOps work that must take place to enable continuous delivery, but unfortunately most DevOps practitioners are trying to use outmoded approaches or rejecting tools as viable to addressing these needs. For example, teams have tried using Wikis and SharePoint sites, “It’s on the Wiki” is an all too common refrain. Or they have fallen back on endless meetings, email chains, and real-time IMs that are limited to only select participants and with knowledge that is shared and then lost in an inbox or disappears when the IM is closed. And most DevOps practitioners will tell you they have rejected the CMDB and service support change management tools as well, because they a) don’t trust the data in their company’s CMDB (or perhaps multiple CMDBs) and b) believe traditional ITIl change tools are far too process heavy and actually work against the goals of agile development and delivery.

What we need instead is a place where Dev and Ops teams can actually work together and collaborate with the business – all the way from requirements planning to post-deployment issue resolution. This new workspace shouldn’t replace the tools that each group is already using and it should work with existing ITIL tools too. Instead, its purpose is to provide a unifying layer that brings together the relevant information and knowledge across the DevOps lifecycle, and employs modern social collaboration techniques to notify and engage individuals based on what they are responsible for and have opted into caring about. What’s more, it should leverage information from CMDBs and discovery tools along with a range of other information sources, and provide a mechanism for peer review to validate this information continuously, fill in gaps, and correct bad information too – so that Dev and Ops practitioners have a place they can go to access all the information they need to do their daily work efficiently and make accurate and timely decisions that move the business forward.

With a new DevOps workspace like this, we can finally overcome the limitations of traditional IT management tools, outmoded collaboration practices, and embrace tools that are built to support DevOps practitioners and their interactions. It’s what we call an IT agility application, and it’s what we offer at ITinvolve. You can read more about how it works in this in-depth use case document.

Matt Selheimer
VP, Marketing

The Ends Justify The Work

Monday, December 2nd, 2013

My first big corporate IT job was with a major electronics company. I did desktop and server support for the smallest business unit in the company that had maybe 200 employees and just north of a billion dollars in annual sales. I loved working for the smallest group in a big company, because I got to know most of the 200 folks that worked there and I had access to all of the resources of a Global 50 company.

About 6 months into the job, the Director of my group left and a new guy was brought in. The new guy was fanatical about customer service and creating a partnership with the business. I immediately liked him. Unfortunately, not too many others did. He wanted to change things in a big way, but no one else wanted to change. He only lasted a year, but in that year he did a few things that helped shape how I approach my work to this day.

One of his first actions was to send everyone in IT to a 7 Habits of Highly Effective People class. Being the good corporate citizen that I am, I negotiated attending the class in San Diego as it was only 90 minutes away from a sales office that I supported just outside of LA. I could save the company money by combining the 7 Habits class with a site visit to the office. Did I forget to mention that this was in February and it was zero degrees where I lived?

I loved the class. 20 years later, the primary thing that I remember and try to use daily is this – Habit 2: Begin with the end in mind.

Basically, how can you get somewhere if you don’t really know where you’re going? This is amazingly relevant to folks in IT, yet rarely practiced.  We usually do a good job at our assigned tasks, but do we really understand why we’re doing them? Everyone from code developers to infrastructure people to support and operations folks are working towards a common goal. That goal is to move our respective businesses forward. Unfortunately, we’re usually too busy being heads down on our individual tasks to see and understand what we’re really doing.

My company, like most companies, had a set of annual goals. As I recall, they went something like this:​

  • Deliver great products and service
  • Service existing customers well
  • Innovate to deliver new products
  • Improve the quality of existing products
  • Improve customer retention

IT plays a key role in the achievement or failure to achieve these goals. For example, the project you’ve just been assigned to that requires you to work late nights over several months wasn’t funded and put in place simply to keep you busy. It was funded and put in place to achieve one of those company goals.Unfortunately, many rank and file IT practitioners aren’t really aware of their employer’s goals, let alone how their daily work supports them. I’d go so far as to say that many managers, directors and even higher ups would struggle to list the company goals for the year.

So, why is this a big deal? Some might say, “I don’t need my database developer to be aware of what the company is doing. I pay her to develop databases.”That’s both correct and completely wrong at the same time. Yes, you might hire her to develop databases,but what is your company actually paying her for (hint: it’s not just to develop databases)? She is a member of the company as a whole, not just some cog in an IT wheel. She is a stakeholder in the company’s success, and chances are she’s pretty good at what she does otherwise she would have been let go or outsourced.

Regardless of how good your IT team members are, I think the majority of them can make more of an impact and feel satisfied by their work just by understanding why the work they do is important to the business.

Case in point – I remember being in a meeting at a pharmaceutical company I worked for some years later. The purpose of the meeting was to discuss how we were going to roll out a new application to support what our Research and Development teams were doing. The conversation got way down into the technical weeds and I blurted something out like – “It doesn’t need to be this hard…It’s not like we’re trying to cure cancer here.”  A very quiet gentleman at the head of the table cleared his throat, stood up, walked over and gave me his business card. He was the VP of Oncology R&D. He was trying to cure cancer. My company was trying to cure cancer and that meant each of us in IT were trying to cure cancer – including me. Talk about a wake up call.

This one meeting was a shot in the arm to remind me again to always practice Habit 2: Begin with the end in mind. If you know where you’re going, it’s going to be much easier to get there and help you make better decisions along the way.

After that meeting, I put some time on my Director’s calendar and asked him to work with me over the coming days to help me map what my team did to what the company’s business goals were. In some cases, it wasn’t that easy. How did a new storage array contribute to releasing 10 new pharmaceutical compounds?  How did a new desktop image enable revenue growth of at least 7%?

This is our challenge in IT, and you have to figure it out. Teach you peers and the folks on your team that by organizing your projects and tasks according to business goals, it’s going to be easier for everyone to prioritize your work and make better decisions. It’s going to be easier for everyone to go through your end of year review and answer questions like – “What did you do last year that was valuable to the company?”

What we do in IT matters. It matters to our customers. It matters to our employers and it should matter to us. But, first, you must understand how your work enables the business to achieve its goals. Only then, will you fully understand why your work really matters.

If you’re a rank and file member of IT that can’t get answers from your boss to help you connect your work to business goals, then keep pushing but also take the initiative yourself. Read your company’s annual reports and SEC filings. Maybe even take the bold step of requesting a meeting with your CIO. Walk into that meeting and say, “Hi, I work in this department and I do X. I want to help our company move forward as best as I can. I’ve been reading about our company goals and I want to be sure the work I do supports them. Can you help me validate that the work I am doing is what the company wants me to focus on to help deliver on our goals?” You may be very surprised (in a good way) at the response you get.

Joe Rogers

Director of Technical Services