Author: Ruston Vickers

  • A Winning DevOps Approach for Established Enterprises: Pace-layered

    A Winning DevOps Approach for Established Enterprises: Pace-layered

    Does your bank offer the ability to deposit a check by taking its picture with your smartphone? When that feature debuted a few years back, I remember thinking it was interesting and convenient enough that if my bank didn’t offer it soon, I’d be willing to switch to one that did.

    I bring this example up for two reasons: one, it’s a microcosm of the larger race to innovation that is happening in every company and industry as we speak; and two, it involves banks, which are good touch-points for a discussion about the unique challenges established enterprises face as they attempt to implement DevOps practices in their IT organizations.

    We know that DevOps means incorporating best-practice application delivery methods that improve communication, integration and collaboration between development and operations, but what is its ultimate goal? Quite simply, getting high-quality services to market faster than competitors – at a cost that aligns with both IT budgets and business goals. And as my check-depositing story illustrates, if you’re not first in the market, you at least need to be nimble enough to catch up, or you risk losing customers.

    For long-time enterprises, this can be easier said than done. In my previous blog about DevOps culture, I used Etsy as an example of an organization that has had great success with its DevOps transformation, but the e-commerce company has been around for less than a decade. Its young IT architecture is apples to the oranges of established enterprises, whose complex environments often comprise a mix of legacy and modern technologies that have been cobbled together over time.

    As a result, the DevOps journey is typically longer and more difficult for such organizations – but that doesn’t mean they can afford not to pursue it.

    Improving Deployment Practices at Every Infrastructure Layer

    When you look at the IT infrastructure of an established enterprise, you normally find three layers of technology. Let’s call the first “systems of record.” These are the legacy transactional systems (often mainframes) that have been with a company since the beginning. They do their jobs well, but their size and inflexibility make them resistant to the type of Agile development that DevOps typically embraces.

    The next layer is “systems of differentiation,” or the various hardware, software and middleware components an organization accumulates as it grows, merges with/acquires companies and enters new markets. While these systems are often more Agile-ready than the systems of record, their decoupled/distributed nature can complicate and slow down development and deployment processes.

    Finally, there is the “systems of innovation” layer, which is made up of mobile and Web applications and leverages the latest technologies. Because of its light footprint and flexibility, this layer is the most adaptable to DevOps practices. In fact, as you move up the layers from systems of record to systems of innovation, the holy grail of high-quality, fast and low-cost deployment becomes more and more attainable.

    What does this mean from a macro perspective? Basically that established enterprises need to take a pace-layered approach, where application delivery occurs at different paces within the different areas of their architectures. The point, though, is to improve in each layer.

    So if an organization pushes out a mainframe update once per year, perhaps it can move to a bi-annual schedule (with support from the right people, processes and technology, of course). On the other hand, a Web team that publishes updates once or twice a week could leverage DevOps tactics and technologies to adopt a daily update cadence. Bottom line: Different deployment paces are fine across layers, as long as improvements are occurring across the board.

    Kick-starting the Journey with Service Virtualization

    Now that we know why the DevOps journey can be difficult for established enterprises, let’s look at how one such organization, namely Union Bank, overcame these challenges and achieved success.

    According to an article on Bank Systems & Technology, Union Bank was looking for ways to compete with top-tier banks, so it began “acquiring other institutions, updating legacy systems and launching new front-end applications.” In order to support these efforts, the bank implemented a service virtualization solution, which simulates constrained or unavailable systems across the software development lifecycle (SDLC). This allowed its developers, testers and performance teams to work in parallel for faster delivery and higher application quality and reliability.

    Here are some of the results Union Bank has achieved since:

    • Cut testing environment setup time from 42 days to 3 days
    • Slashed three and a half months from mobile and Web application development time
    • Reduced the cost of testing cycles by 65 to 85 percent

    Obviously, a service virtualization solution is only one piece of the DevOps puzzle, but Union Bank stands as a powerful example of how a long-standing enterprise can leverage such a tool to be more innovative and nimble in the marketplace.

  • In the DevOps Journey, Culture Comes First

    In the DevOps Journey, Culture Comes First

    Etsy, the global marketplace where people sell handmade goods, vintage items, craft supplies and more, has grown by more than 10 times since Chad Dickerson joined as CTO in 2008.

    While the organization’s success is obviously the result of numerous factors, it’s no coincidence that upon arrival, Dickerson initiated a significant culture shift in how the company’s development and operations teams deploy updates to the front- and back-end of the website.

    What kind of culture shift? If you saw my title in the byline, you probably know that I’m talking about DevOps. But before we get into why culture is so important to DevOps, let’s back up a bit and make sure we’re all on the same page about what DevOps actually means.

    At CA Technologies, we define DevOps as best-practice application delivery methods that improve communication, integration and collaboration between development and operations. In layman’s terms, this means development and operations teams work on software releases in tandem, rather than throwing code back and forth across a silo. The result? Their collaboration helps companies release high-quality software and services to market faster and at lower cost.

    The “why” of DevOps is simple: In an ultra-competitive landscape where companies are racing to release the next big thing, software quality and speed-to-market are essential for achieving business goals and creating differentiation. It’s the “how” of DevOps that can be confusing. So let’s talk about where that begins – namely, with culture.

    A Vision for Transformation

    When it comes to something as significant as a culture shift, it’s not about just getting development and operations teams in the same room for a few meetings. We’re talking about breaking down long-standing silos and changing the human fabric intertwined with them – an undertaking that requires both top-down and bottom-up strategies for change.

    I talked earlier about the change Chad Dickerson brought with him when he joined Etsy as CTO. In a blog post from his early days in the position (he’s now the company’s CEO), Dickerson talked about the importance of “intellectual honesty,” which he described as “admitting when something is not working so you can work together to figure out how to fix it” and “measuring your successes and failures so you can properly reward for excellent work and learn from your failures so you can strive to never make the same mistake twice.”

    It’s clear from his words that Dickerson had a high-level vision almost from day one for how to transform Etsy’s IT operations, even as he admitted that there would be “bumps” along the way. This kind of vision is essential for driving the DevOps journey and keeping it on track as opposition, challenges and other issues crop up. It’s been said before that DevOps takes a village, but you can’t have a village without a chief.

    Populating the Village

    Speaking of the village, if the chief is supplying the top-down vision, it begs the question, who is going to carry that vision out? This can be tough to answer, especially in organizations where development and operations teams have been entrenched in siloed practices for decades.

    In my own experience, I’ve seen the village successfully get on board the DevOps journey when its involvement begins as a grassroots movement and grows with small wins over time. In other words, the chief pulls together a group of IT professionals with similar characteristics – think driven, highly skilled, unafraid of change – and they work to transform just a single deployment scenario (e.g., pushing out Web updates). At the end of that experiment, the team shares its experiences, challenges and successes with the larger IT group in the hopes of bringing more people on board and moving up to more significant deployment scenarios. Then, it’s rinse and repeat until the culture shift has occurred.

    It’s worth noting that in situations where the development and operations silos run especially deep, a rip-and-replace option may be the only viable one for achieving DevOps. In such cases, leadership has to put forth an edict saying “this is the way it’s going to be” and expect to deal with some attrition, as there will be employees who simply refuse to change.

    A Formula for Change

    We’ve talked about the chief and the village, but I’d be remiss if I didn’t touch on the nuts and bolts that are necessary for engineering such a culture change. Yes, top-down vision and buy-in from the bottom up are important, but so are the new tools, skills and processes required to support that change.

    There’s a reason the word “journey” is so often used with DevOps – it’s a never-ending cycle of optimization among the people, processes and technologies driving development and deployment operations. So as you evaluate your own culture and think about the next stop on your DevOps journey, remember this formula: vision + expertise + tools = change.