The intersection of DevOps and culture is a common subject here at DevOps.com. 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.

DevOps.com: 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.

DevOps.com: 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?

DevOps.com: 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.