DevOps managers encounter challenges when a fast-growing IT operation fragments into so many different departments that software delivery and performance lag. CoreLogic, a financial analytics service provider based in Irvine, Calif., faced this very problem just a year ago. Its DevOps team of 300 full-time employees and a few hundred contractors worked in small groups, each with its own set of applications. As a result, the company ran many redundant apps and DevOps processes, according to Robin Gordon, CoreLogic's new chief data officer and, until recently, the company's Solution Management Center senior VP.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
"Each of CoreLogic's development teams operated within their department and didn't collaborate with other developers in the companies," said Gordon, who started at CoreLogic in June of 2013. "Each supported a particular business unit and really only had exposure to those systems."
In the following Q&A, Gordon talks about the problems caused by siloed DevOps, the steps taken to address those problems, and how her team chose online collaboration tools based in software as a service (SaaS) to foster interactivity, fix a broken ticketing system and consolidate processes.
What problems arose from departmental or decentralized application ownership at CoreLogic?
Robin Gordon: It was a problem for a variety of reasons. One, [the developers] didn't feel like they belonged to the larger organization. More important than that, from just a pure application development standpoint, they didn't see where there were capabilities and opportunities to improve their applications in other areas. So, whether it was a matter of reusing components in their area or leveraging technologies that other groups had utilized, they just didn't have exposure. Their world was very myopic to the area that they supported.
What first steps did you take to break down departmental silos?
Gordon: I addressed this initially by doing road shows and going out and meeting with each of the groups and trying to share a little bit more about our corporate objective, our global technology objectives. But that can be a pretty long-winded, inefficient process for me to be traveling to numerous locations across the country.
Which other online collaboration tools or technologies did you evaluate or use?
Gordon: Other options included Chatter, which was part of the Salesforce.com platform, Yammer. But it's just a platform to facilitate collaboration. You get onto Yammer, you have a conversation. The conversation is done. You move on. I've seen in my career, [introduction of] social media [that] falls by the wayside because it feels like extra work to do … and there's no objective. [Then we heard of the] POPin tool, a SaaS that allows open discussion of a topic in a casual way, not like social tools or surveys.
How did you evaluate POPin?
Robin: We launched a pilot of POPin, where I took about a hundred team members, randomly selected from different areas of my team and all different levels of my team. We just asked them a simple question: 'How do we become more effective as a complete cohesive team versus individual units?' The session lasted for three days [and let people] suggest and then build on each other's ideas. It doesn't feel like extra work. It feels like a more efficient way to do your current work.
What technology or development tool changes were suggested during this trial run?
Gordon: We had an outstanding result. I think there was over 90% participation rate. We got about an 80% engagement rate. I think we had about 75 ideas come out of this session. There were hundreds and hundreds of engagement points, where people were coming in, voting on ideas, commenting on ideas, adding new ideas.
It was a compelling exercise, in terms of really hearing from the people and getting an objective perspective on what was really bothering them and where they saw opportunities for improvement. They were engaging at a level that I don't think the team had ever engaged before; interacting as a cohesive team for the first time, instead of interacting in the silos that existed before.
What was the most common collaboration problem mentioned in this first feedback session?
Gordon: The first idea that rose to the top regarded the ticketing system that our app team has to interact with, whether they're fixing their laptop, getting a new cellphone, ordering a new server or running a patch. That tool is incredibly cumbersome, not intuitive at all. People felt like it hindered their ability to be effective in their jobs.
Were you able to use online collaboration tools to address the ticketing system issues?
Gordon: We already knew that that ticketing system was pretty bad, and we'd generated a set of high-level requirements. But we said, 'Instead of the normal approach of talking to user groups and building out requirements, what if we held a POPin session?' We did it as a sprint, over the course of an hour. [About 300 users and administrators] called into a conference line and engaged in writing requirements for an hour. Then we left the session open for 24 [more] hours.
Then, we looked back to the requirements that we had internally and the broader set of requirements developed over the POPin session. There were a lot of common themes. The POPin session helped us prioritize the things that were causing the most pain, the most egregious problems in the tool. We did not have to guess at it, as we had done in the past.
As a requirements gathering process, it was a really cool way of engaging the team and getting the right set of priorities.
What ideas for collaboration processes came up in that first session?
Gordon: It was the idea of creating a knowledge base of reusable components that team members could leverage when they were building out new systems and augmenting existing systems. They felt like they were doing a lot of repetitive work, probably recreating the real and numerous instances. That was actually the truth. They wanted some way that they could interact more holistically with other application development teams across the organization, so they could see nuggets of code that they could utilize in theirs.
The other idea was very similar, but more focused on creating a community practice, where the developers could share ideas, gain knowledge, build up their skills and become more integrated as a team.
How did your team act on those process ideas?
Gordon: Small [collaboration] groups sprouted out of this idea. We have Tech Tuesday or Tech Thursday, where small groups of people talk [via POPin] about how to solve problems in terms of new technologies, coding techniques, training on new versions of software development tools and what-not.
Generally, grass-roots teams became more acceptable to the entire organization. Instead of five people joining Tech Tuesday, we maybe have 50 people joining Tech Tuesday. They're really collaborating and learning from each other about how to be more effective and how to fine-tune their skills sets. So, that was the result of that first session.
What are your plans for increasing collaboration in the future?
Gordon: I now run CoreLogic's data organization, so I'm bringing POPin over to my new team. Also, I do have an application development team that reports in to me that supports the data supply chain.
I want to use that tool to get ideas around what's working and not working within the data supply chain, and how we can more closely connect with the corporate technology organization that I was in. The [data] team here is larger and probably more dispersed, not location-wise, but if they are working in one area, they are absolutely not aware of other areas. I definitely want to bring people together more effectively and start to map out our end-to-end processes so we can improve and be more effective within our data organization.
Learn more about transitioning legacy software to SaaS
Discover more about creating a strong SaaS risk strategy
Learn five ways to tell if you're ready for SaaS ERP
What role should tools play in a DevOps initiative?