Large enterprises appear to be monoliths, but, in reality, many are conglomerations of related yet functionally different businesses. These businesses may have different IT infrastructures, skills and resources at their disposal.
Hearst Business Media employs 27,000 people globally to provide information to various verticals from automotive to healthcare. Within the enterprise, IT groups possess varying levels of DevOps expertise and levels of adoption. As a DevOps program manager, Alexa Alley facilitates corporate-level programs to help these businesses reach higher levels of DevOps maturity. One such program is value stream mapping.
"Value stream mapping workshop sessions ... have been by far one of the most successful things that we've been able to implement," Alley said.
Map the whole value stream
The value stream mapping process enables IT organizations within Hearst to identify areas for improvement.
Value stream mapping usually starts with the product person or team as they are the direct line to the customer, Alley said. The process moves through the development lifecycle, QA testing, release and operations, and how the IT team monitors and manages this product or feature after release. The value stream doesn't end there; it looks down through deployment and up at the customer to see if the project achieves its goals.
The value stream mapping process assembles everyone involved with a workflow into the same room at the same time, to clarify their roles in this product delivery process and identify bottlenecks, friction points and handoff concerns. Value stream mapping reveals steps in development, test, release and operations support that waste time or are needlessly complicated.
At Hearst, value stream mapping led to automation within the toolchain and within quality assurance; communications across ops, QA, dev and product team members; and more focus on business value for applications and IT initiatives.
"This is where you get the 'aha!' moment -- where people really understand how they fit into the valuation, how they fit into the workflow and how they help to move these processes forward faster," Alley said.
What's in your DevOps toolbox?
Ideally, developers and ops teams use the same tools for tasks such as configuration management and monitoring. Within Hearst, the teams at the higher end of the DevOps maturity spectrum have this shared toolkit. At the minimum, tools should communicate and integrate with each other, allowing seamless handoffs of information or tasks between the team's toolkits.
"We want [the cross-functional DevOps team members] to be using the same tools for continuity's sake ... so you aren't throwing things over the wall," Alley said.
Hearst Business Media recently implemented monitoring across all its teams to create visibility from one step to another, so everyone can get involved in the release process. For example, developers help write smoke tests for code, and ops can help facilitate tests -- and both groups have visibility into how things go in QA. "They know what's [going to happen] in production before it actually hits production," Alley said.
DevOps is about helping each other
While businesses are at different points in the DevOps adoption process and may possess different skills, they often share friction points with other groups in the company. Alley connects businesses that have the same roadblocks so they don't have to reinvent the wheel to solve it.
"We want to work together regardless of your email domain," Alley said. Her definition of DevOps is more than how to break down silos between dev, ops and related groups -- it also covers how to break down silos between ops and ops, dev and dev, and even one team's ops to another team's QA. The same collaboration tools and automation will work -- maybe with adjustments -- in multiple situations. Sometimes all it takes is a chat between two teams, Alley said, to figure out the answer to both their problems.
DevOps is, Alley said, "helping people outside of just yourself and your team to make everything better."
DevOps is also about continuous improvement. The value stream mapping process doesn't happen once and end there. "These are iterative, and they need to be revisited and redone regularly to understand what's been accomplished," Alley said. New places for automation crop up, as do more ways to integrate teams across IT.
Transcript - A value stream mapping process is best under a DevOps approach
Meredith Courtemanche: I'm Meredith Courtemanche from TechTarget. I'm here with Valerie Silverthorne and we're speaking with Alexa Alley from Hearst Business Media. So Alexa, you're a DevOps program manager. Can you tell us what your role is within Hearst and how Hearst works with DevOps in their different groups?
Alexa Alley: As a program manager, I help to run and facilitate a lot of the programs that we implement at the corporate level to help these individual businesses that Hearst Business Media owns and operates, move toward this DevOps transformation that we're working to achieve and spread throughout the entire company.
Value stream mapping is one of those programs we do, internal consulting engagements and a variety of different programs, but I help to run/manage those and make sure that the businesses are getting value out of those to help move their business forward and help to contribute to the overall Hearst Business Media goal and mission and objectives.
Courtemanche: So Hearst is a lot of companies within one company, and they're all probably in different areas of DevOps maturity, is that fair to say?
Alley: Absolutely, yeah. Everyone's at a very different point in the transformation plan and where they're looking to be in adopting DevOps.
Courtemanche: You talked at the DevOps Enterprise Summit here today about mapping value streams. Can you kind of explain what value streams are, how you map them and why you do that?
Alley: Thee value stream mapping workshop sessions that we do have been by far one of the most successful things that we've been able to implement. It helps to get everybody who is part of a value stream or a workflow in the same room together at one time.
It usually starts with product because they're getting a request from the customer. It goes all the way through the development lifecycle, QA testing, release ops and how they monitor and manage it afterward, back up through deployment [and] back to the customer.
Often this is the first time that these teams have all been together at once, and so this is where you get the "aha moment" where people really understand how they fit into the valuation, how they fit into the workflow and how they help to move these processes forward faster.
Doing these helps the businesses to identify where there are bottlenecks, where there are friction points, where work isn't handed off efficiently and then we work to build a transformation plan at the end of it, and [ask] how can we streamline this? How can we go from deployments twice a year to maybe quarterly? Maybe we want to do it monthly. But we build out this plan that really helps the teams understand what they can be doing in their day-to-day workflow, and their work cycle to help move their own processes forward as well as that of their team to fit the business goals and objectives.
Leadership is a part of this. The individual contributors are part of this and they all have to support and understand what we're trying to do with these workshops and moving forward. These are iterative and they need to be revisited and redone regularly to understand what's been accomplished in say phase one. What's changed and how can we continue to change it?
We continue to do these value stream mapping workshops. But we're going to be working really heavily on QA in the next coming year. How can we embed QA in the dev teams, and how can they start working together so that you're building these automated tests with developers and developers can help build these tests with QA? And maybe there are cross-functional teams that are working together -- and that's one of the biggest initiatives for 2017 for sure. And then also automating more of the tool chain.
We want to automate more of these processes and that's what some of these value stream mapping workshops have helped us to notice is there are a lot of manual processes that aren't necessary to be manual. We want to automate a lot of those and give these teams the ability to work on things that they're passionate about and that they're excited about.
I mentioned tech debt is a big thing on people's radar that needs to be addressed and worked on. Our developers and our ops [are] excited to work on it because they know it's going to help. We're trying to help them do that and really achieve that.
Valerie Silverthorne: When you talk about your developers who are kind of in the DevOps struggle right now, what do they struggle with most?
Alley: I think a lot of it is understanding the business value and the business props … what are we trying to achieve with these new features and how do we build new features and products that are ahead of the market? We don't just want to be catching up. We want to be pushing the change and pushing the initiative.
We want Hearst to be leading this DevOps transformation and creating goals and objectives for developers to understand how we can do that and what we can build right the first time. What is our MVP and how do we continually iterate that to fit the need of our customers and stay ahead of market? And how do we include QA and all of that? How is ops a part of this the whole time? How can we get product working with us and those product teams to really understand what we're doing so that we can provide the most value to our customers?
Courtemanche: You mentioned toolchains earlier. Are your developers and ops teams using the same tools, the same configuration management tool handling software and servers?
Alley: Ideally, yes, or at least ...
Courtemanche: That's at the top end of the maturity.
Alley: Yeah, absolutely, and we want at least for the tools to communicate and integrate well with each other. We've implemented monitoring for all of our teams and that's been a huge success and a win for Hearst Business Media to really understand how things go from development. Are they working in QA? Are they passing these smoke tests … dev often helps to write these tests so ops can understand and help to facilitate [so] they know what's happening in the production before it actually hits production. We want them to be using the same tools for continuity's sake so you are throwing things over the wall in there.
Silverthorne: When you say monitoring, are you talking APM, DPM?
Alley: APM most often yeah, we use New Relic pretty heavily and Sumo Logic.
Courtemanche: Do the same bottlenecks appear from one business to another? You're probably seeing all these different businesses from a higher level. Are you seeing the same pain points from one to another?
Alley: Often they share a lot of those friction points and it helps to be more of their corporate level and go down and understand where we've seen these before, in a different business, and how a business in the automotive vertical can help a healthcare vertical because they're finding these same friction points. Maybe it's in all of the manual processes and using a shared drive that you have to pull down work and then we push it back up before anybody else can see it. You can't cross-collaborate and work on these things together.
What can we do to implement and help improve that? Where can we sit the teams together to help move this forward and get these teams and these tools talking to each other? A lot of these bottlenecks occur fairly frequently and maybe they're just teams not working together, maybe there aren't face-to-face meetings enough. But you want to identify those early on and we've been able to connect multiple different businesses with each other in different verticals to help them build and implement these tools that have already been done by a business. So why would you do the rework?
Courtemanche: Right, and then share it across.
Alley: It's been helpful.
Courtemanche: When you say [it's] already been done by a business, you mean within the greater Hearst umbrella?
Alley: Right, within the greater Hearst umbrella and we want these teams to work together and that's why we have them as part of the Hearst family. We want them to work together and have this cross-collaborative community regardless of what your email domain is or where you physically sit. Everybody should be talking to each other and helping each other.
Courtemanche: Now is that part of your definition of DevOps ... not just dev and ops working together but dev from this group working with dev from that group and ops from this group working with QA from this group and sharing information? Is that how you define DevOps?
Alley: Absolutely yeah. We want these teams regardless of job function, or title or business, to talk to each other and help each other and that is what DevOps is. You're helping people outside of just yourself and your team to make everything better.