Tag: ITInvolve

The intersection of DevOps and culture is a common subject here at devopsy.kinsta.cloud. Is it tools and processes that help support the culture, or does the culture of an organization drive toolset and process building decisions? Perhaps a little of each. We recently had a talk with Matthew Selheimer, Chief Technical Evangelist at ITinvolve, a Houston, TX-based maker of IT collaboration and workspace management applications.

devopsy.kinsta.cloud: Tell us a little about ITinvolve, and the IT challenges the company tries to solve?

Selheimer: One of the core challenges that the founders of ITinvolve identified was the fact that organizations really didn’t have an effective understanding of their environments, and all of the associated dependencies. It’s a reflection of how today’s configuration management efforts, using their databases and discovery tools, fall short. They only filled in part of the picture, and a lot of times organizations spend a significant amount of money investing in CMDB initiatives only to have people not even bother to use the data. Maybe they didn’t trust the data sources, or they had their own private systems, spreadsheets and things they were accustomed to using, and they kept using those familiar toolsets.

The founders took a close look at what could be achieved if we apply the principles of Enterprise 2.0 to the way IT is managed. What if we actually embrace the notion that it’s all about people, process, and technology, and in that order, instead of not putting technology or the process first. That is, historically, the approach of many management vendors. So ITinvolve was founded on the principle of embracing people as the most important asset in the IT organization.

I know you’ve been in the industry for a long time, so you’ve lots of anecdotes you can look back on your career where it was either that the tribal knowledge created the great success – or it ended up creating the great failure. And when people left an organization, the business was at risk because it was so dependent upon tribal knowledge, or even a single person. So, when they left the company, there was a big freak-out because they knew how everything was configured and why it was configured that way and that tribal knowledge was something that couldn’t be lost.

 

devopsy.kinsta.cloud: With that dynamic in mind, are you seeing DevOps impact traditional CMDB usage? Are organizations using them widely, or are they still more a promise than reality?

Selheimer: I think these are real problems that organizations continue to struggle with, that there is so much risk involved in change because we’ve cobbled together all of these architectures and infrastructures over the years. That was the core idea behind the company. And the initial effort product was to take discovered data – CMDB data, SharePoint data, Visio diagrams, all the scattered data sources – and bring them together in a way that is visual, logically organized, and within an application that people want to use.

We were initially focusing more on the traditional ITSM market, but what led us to the DevOps market is that DevOps is the area that has everybody’s attention, because it is so much closer to what the business really cares about. At the end of the day, resolving incidents and delivering better customer support and customer experiences, are critical parts of the IT organization. But how do you actually get applications developed and employed, how do you modernize legacy infrastructures and legacy applications, which aren’t going to go away? How do you mobilize the front end of them and those kinds of things?

 

DevOps: Automation helps, but it’s not about just automation for the sake of automation. The danger there is you end up just accelerating bad process.

 Selheimer: Kevin Behr and I were talking about this a couple of weeks ago. We concluded that automation is the last thing you should do. What you really need to be doing first is figuring out how to actually get the mindset shift necessary for people to start thinking about end-to-end flow? It’s not about optimizing a workstation, it’s about thinking in manufacturing terms. It’s about flow all the way across, and that starts with requirements and what we’re trying to achieve from a business standpoint. That carries all the way through to the actual deployment and their ongoing operation.

But there are huge communications gaps when it comes to attaining that end-to-end flow that are not being addressed by traditional communications – whether that’s conference calls, whether that’s email and instant messaging, whether it’s SharePoint sites. We see pockets of collaboration, so you have GitHub on the source code side of things. You’ve got some collaboration products that are doing some level of basic Wiki and other kinds of collaboration. But there is no real collaboration engine that’s really orchestrating that flow.

So we see that there are a lot of gaps in this DevOps tool chain. Things are still getting passed on down to operations, which doesn’t have enough clarity as to what is needed, why it’s needed, or when it’s needed. Organizations have been able to overcome these challenge on a small scale. A lot of the DevOps science projects that are out there haven’t fully seen this issue yet. I was just reading O’Reilly’s book DevOps in Practice, which profiles a case study with Nordstrom and a service provider for the Texas government.

I think that is a great book. It is a great example of the maturity of DevOps. So I can take a small project and a small team and I can say, let’s go stand up this project around how we are going to start doing middleware configuration and automation better. And bite off that little piece of it – and have some degree of success in being able to have infrastructure as code and that well-bounded box. But, once we start trying to think about taking this up to full-scale applications – once we start thinking about taking this outside of a new generation web company that’s grown from the ground up using agile principles but doesn’t have a lot of legacy – and start trying to apply this to JP Morgan Chase, or to Merck, or to big companies that have duct tape and baling wire holding all of these legacy applications from mainframe to everything altogether, that’s something different altogether.

I think that’s where these communication problems are really going to be amplified in a big way. And that’s what we’re seeing some of the dialog that we’re having with prospects and the marketplace – around how to really do DevOps at an enterprise level. How do we take it out of these small-scale projects where you can have this startup mindset and actually start applying that to 300 people scattered across five, six, eight different time zones and eight different nationalities?

 

devopsy.kinsta.cloud: How do you that? Is that culture? Is it learning how to work across silos?

Selheimer: Everybody has been saying that culture is the challenge, right? It’s the ability of the organization to adopt a different mindset; it’s the ability of people to think more in terms of the end-to-end process as opposed to their particular area. It’s the old silo versus flow debate. My position on that is we have to have silos, and we have to have expertise. There are still heart surgeons in the world and there will always be heart surgeons in the world. But what we need is this kind of T-shape. We need the vertical siloed expertise, but we need the horizontal flow coming across as well. And we have to tie the conversation together and create opportunities for serendipity and for people to engage and to collaborate in ways they haven’t been able to do before. That’s what success looks like.

Enterprises try to do this in an ad-hoc way today. It’s with the water cooler conversation, but generally that ad-hoc happens within a function of the organization, rather than a cross-function. So, one thing I recommend is to have your developers and system administrators have lunch once a week. Have your teams get to know each other better and understand each other’s work better. That’s what is important when it comes to culture change.

When the thought leaders in DevOps get onto their soap boxes, it’s pretty much a guarantee that at some point or other the discourse is going to turn towards culture. But often the speeches and conversations never dive deeper than platitudes about putting emphasis on people over tools.  As true as it may be, though, most newbies want to know what that really means. How exactly does an organization shift to a DevOps culture?

Answering that question should start with a little bit of translation. When speakers hit the conference circuit, generally their references to “culture” are interchangeable with “collaboration.” An organization with a healthy DevOps culture is an inherently collaborative one.

Take a hypothetical situation where an DevOps organization is setting a requirement for a certain  amount of performance throughput on an application, says Matt Selheimer, chief technical evangelist for ITinvolve. Developers in a traditional organization with that requirement would probably have to scratch their heads and wonder how to write the code, and figure out what middleware components they’d need to deliver that level of throughput. But an organization running with a collaborative DevOps culture would ideally give operations folks visibility into that project much earlier in the process.

“They might be able to come and say, ‘Hey, we can solve that through upgrading the IO on the storage area network, and if we do that, that will shave two weeks off your development schedule, and we’ll be able to deliver that faster to the business,’” Selheimer says. “So it’s those moments of opportunity — those synergies that you get when you get people engaged and when you get people who have like interests following one another and engaging one another that creates opportunity.”

That’s the ideal organizations are striving for, but it still doesn’t answer that question of how to achieve that culture of cooperation. There’s no pat answer for that, but perhaps one of the catalysts most likely to shift people’s behavior and beliefs is the fostering of a collaborative work environment. And that starts with the establishment of some sort of collaborative infrastructure.

See, sometimes even culture needs a boost from better use of tools. They’re just not necessarily the ones most people talk about when they’re discussing DevOps. Instead of thinking so much about automation tools, DevOps organizations need to prioritize tools and processes that enable knowledge transfer.

“So there’s an inherent bias in the community against tools, and I’ve seen that bias be eroded on the automation side, but I haven’t quite seen that bias be eroded on the collaboration side,” Selheimer says. “It’s time to really take a look at what tools you’re using to collaborate, because I guarantee you’re using tools.  You know, you’re using email, you’re using instant messaging, you’re using SharePoint, you’re using Vizio, you’re using spreadsheets, you’re using phone calls — those are tools. ”

The question is, how effective is your existing toolset at greasing the skids for easy collaboration? The point is that automation may be important, but collaboration is the horse to automation’s cart. The problem is, that too many organizations are putting automation tool sets and processes first, leaving collaboration as an afterthought. That’s dangerous, says Alan Sharp-Paul, CEO of ScriptRock, a developer of configuration management tools.

“The automation of a system is often considered an ‘end’, not a ‘means’. Bad process and bad design become codified because they get buried,” he explained in a blog post. “Taking the necessary steps to ensure collaboration on requirements is often pushed aside in the interests of simply getting it done.”

Obviously, Selheimer has a biased stake in this game—his company creates collaborative software for IT teams. But his point is valid—organizations generally need to establish better mechanisms for their IT workers to share their work, their processes, their tools and system statuses so that they can better establish a continuous delivery model. More DevOps organizations are slowly coming to that realization. It’s why we’re starting to see more announcements from companies seeking to bulk out the collaborative tool box.

For example, yesterday the folks at VictorOps released its VictorOps Transmorgrifier to help organizations bake in more existing documentation, graphs and data about relevant systems into IT alerting. And earlier this month AppDynamics announced the release of its new DevOps Virtual War Room to help consolidate application and system information and metrics. Similarly, not long before that Tasktop introduced a new product called Tasktop Data that’s meant to help act as a data repository for real-time analytics across teams, projects domains and tools. Clearly, the pool of tools is growing deeper as organizations voice the need for a better infrastructure to support cooperation across IT tribes.

But that doesn’t necessarily mean that mechanism has to be expensive or complicated. It just needs to be more cohesive than a bunch of disparate documents spread out across multiple locations.

“There’s got to be a centralized, secure, well-lit place where people can document how everything fits together,” explains Chris Clarke, senior vice president of product management for CollabNet, saying that even something like a Wiki or a meta site can help  organizations start to link together documentation about processes, architecture diagrams, pointers to tools and so-on.  The simpler that an organization can make it for team members to share information like that, the more likely they’ll start working closely together.

This consolidation and dissemination of knowledge is also crucial for the long-term resiliency of DevOps teams. As many more organizations seek DevOps-savvy personnel to help jump-start their continuous delivery programs, employee turnover can pose danger to those organizations whose knowledge base is concentrated around a few DevOps rock stars or isolated teams.

“Churn can be dangerous because you get enough little islands that are each trying to satisfy their own goals and you get the superheros on those island and then effectively what happens is those superheros walk out and those islands blow up,” Clarke says.

This is why effective infrastructure for sharing knowledge is especially important  in 2015. According to a recent survey by Rackspace, only about 38 percent of organizations who currently use DevOps for all applications across the organization. However, approximately 20 percent more of these organizations are currently working on pilot projects. And among those who haven’t yet implemented DevOps, nearly 50 percent say they have plans to fully integrate development with operations in the near future. Effective collaboration will be critical in ensuring success as as large organizations push simple DevOps pilot projects to full-blown IT departmental transformations. On the enterprise-wide level, collaborative infrastructure lag becomes unsustainable.

“If I’m a small startup company and everybody’s all in the same offices, I have a lot more opportunity collaborate in a face-to-face manner,” he says. “But if I’m General Motors or Ford or Bank of America, and I’ve got thousands of developers and thousands of operations personnel scattered across every country and continent, I can’t do that effectively.”