People like success stories -- and the bigger the success, the better the story. Well, they don't get much bigger than Target, which would explain why Heather Mickman, senior director of technology services at the retail giant, has presented at the DevOps Enterprise Summit in San Francisco for the third year in a row.
Mickman has taken on the role of DevOps evangelist at Target, witnessing a few DevOps-inspired change agents rapidly evolve into a companywide movement. As successes become more visible, senior leadership began taking note of what was happening. And when a new CIO was brought on board, the DevOps processes and large-scale Agile transformations were fast-tracked across the organization.
A big retailer starts small
Target, the second largest importer in the United States, has 1,800 stores and a significant online presence, which creates both technical challenges and opportunities to innovate.
It takes a lot of technology to run a modern retailing company, and that is one of the reasons DevOps is so important.
Heather Mickmansenior director of technology services, Target
According to Mickman, Target had accumulated the expected amount of organizational silos and technology debt over its half-century in business. It was time for a makeover to allow this enterprise to keep up with the pace of change. "It takes a lot of technology to run a modern retailing company, and that is one of the reasons DevOps is so important."
Integration would be one of the first tools in the DevOps toolkit that would be used to help tear down the departmental silos. First, interfaces were designed to describe how silos would interact and communicate with each other.
Simply defining a set of interfaces may sound like an insignificant step, but before they created a set of APIs to allow for departmental integration, it might take something ridiculous like four to six months to do something as simple as pulling basic information about store locations into a new system. Data was housed in three different systems of record. Believe it or not, sometimes, spreadsheets were involved. Developing an integration API simplified the communication process in a standard way that was not only useful today, but would be useful to other applications that might be built in the future. It was confirmation of Mickman's belief that a services-first architecture is an important part of adopting DevOps processes.
Best practices for making DevOps work
Mickman offered a number of takeaways for attendees based on her experience with transforming her team to a DevOps process approach, with the first lesson being it takes time to make continuous integration an integral part of an engineering team's work style.
Too often, engineers would want to bypass the Jenkins server if they were convinced their code was good, even if a few persnickety tests were failing on the build. That meant putting her foot down when it comes to quality control, giving Jenkins the final authority on build deployment, even if the quality-assurance team said it was all right to go ahead. One phrase the software developers began to get used to: "We are not deploying into production until we are green."
She also found infrastructure as code was a vital piece of the puzzle, relieving developers of the need to physically configure resources. In an environment of DevOps processes, it helped keep things moving when engineers did not have to spend time thinking about infrastructure. Social coding was another key element for speed and quality. For example, work was more visible and transparent with pull requests for all changes.
Through the years, the DevOps team continued to push the boundaries of what was possible. In 2014, the team was working with 30 APIs that handled 500 million calls per month. They were doing 80 deployments each week, yet had fewer than 10 incidents per month, disproving the myth that more deployments leads to more problems. In fact, Target found smaller, more frequent changes made it easier to identify issues and fix bugs as they arose. Course correction became part of the daily job, rather than a huge crisis.
DevOps and the onboarding process
In 2014, the API count was up to 100, with 27 billion requests. In that year, a new CIO, Mike McNamara, came on board and changed the overall IT operating model and structure. Under his direction, each team owned a product, and Agile became the approach across the board. Mickman appreciated his ability to cut through the noise and figure out what to work on and what was a waste of time. "It's important to have a clear focus, because you can't get everything done." As an example, a top priority in the past year was reducing the error rate for point-of-sale software at the register, successfully reducing customer and employee frustration in a practical and immediate way.
Today, the focus of Mickman's team is the platform upon which they build applications. The goal is to give developers the tools they need to create applications and ship code quickly. That means emphasizing self-service for developers, allowing the provision of environments independently and on an as-needed basis. With these improvements, the onboarding process for new teams and projects dropped from thirty days down to five. Mickman said she's hoping to get it down to as little as two hours.
Enabling teams within the organization is just one way Mickman and her engineers are ensuring the success of DevOps processes day by day. With the full support of leadership within Target, the DevOps revolution has taken hold, and the software delivery process is better off because of it.
