devopsy.kinsta.cloud

Tag: culture

Automation Killed QA – It’s Time to Deal With It

Quality assurance (QA) had a good run.

From the time it was considered an afterthought by organizations and software vendors alike to the era of massive outsourcing contracts, followed by significant vendor investments in related tooling, and, finally, its recognition as a critical success factor among high-performing organizations, quality has evolved to become even more important than functionality to end users.

Customer experience, today, is defined by speed and quality above all else. Namely, can I access the information and products that I want in the blink of an eye and get expected feedback based on input? As a result, customer experience has also shifted: It’s all about application experience, not the friendliness of a checkout cashier or sales/service rep.

With this massive shift toward customer experience platforms (think omni-channel) and increasingly lofty expectations, the operative question becomes, How are we enabling velocity in our testing practices to ensure the highest quality while keeping up?

We’ve tried everything from outsourcing to insourcing, investing in tooling, investing in people and even building testing architecture teams to oversee the automation, quality and consistency of testing results. Roughly seven years ago, my top priority for testing teams was to automate 30 percent of our tests. Today, if you are not 100 percent automated, or close to it, you are severely lagging in output.

But what’s next? What if I’ve automated all of my tests and my manual testers have been replaced with automation engineers, but I’m still having quality issues and being perceived as a bottleneck?

The answer is simple. Automate everything.

Makes sense, right? Isn’t everyone telling you that? But what are we defining as “everything” from a testing perspective? Therein lies the problem; we are thinking about testing as its own factory within the larger software development life cycle.

While we believe we are changing this perception by going agile and moving most QA functions into scrum teams, the reality is we still look at testing as a standalone function. Centralized or decentralized, this is the case, and we need to think differently.

Automating for quality begins with defining requirements. How am I ensuring that I’m covering all cases? How do I ensure I’m translating the business requirements properly? These questions, the time it takes to answer them and the risk of human miscalculation all impact quality and velocity.

We must start our automation for quality at the beginning, during establishment of business requirements.

Let me introduce you to next-generation QA. Intelligent “continuous testing” platforms are replacing humans for testing, automating tests, creating data and building test cases. These platforms are able to translate model-based business requirements into complete automation—test cases, test data and test script automation.

Orchestration across your software development life cycle creates your environments, lays down your test data, deploys your software, runs your test scripts and reports results. No more human error, no costly resources and guaranteed test coverage that ensures quality.

Integrating your existing automation around continuous integration, portfolio management reporting, and execution reporting to this framework now gives you the ability to report and automate your ideas all the way through to outcomes.

Early adopters are already doing this. QA as a functional organization is gone. If you aren’t already automating to this end, you are severely behind.

Questions? Comments? Perspective? Have at it in the comments below.

— Ron DeCanio

January 27, 2017
Increasing Your ‘Bionic Footprint’ with DevOps

“The Six Million Dollar Man” was a 1970s TV series. In the show, NASA astronaut Colonel Steve Austin is severely injured in a crash and is “rebuilt” with bionic features that enhance his strength, speed and vision beyond normal human capabilities. The main tagline was, “We can rebuild him, we have the technology.”

I recently was watching an old episode and it got me thinking about how the show is analogous to the genesis of DevOps—specifically, how individuals with an operations background have to “rebuild themselves” to keep up with the speed and direction of the technology industry.

Over the years, there have been several decrees of “Unix SysAdmins are going away.” I have always firmly disagreed with that assertion. Rather, I believe that SysAdmins have to continually evolve their engineering skills to stay relevant and, more importantly, gainfully employed. It was also becoming increasingly apparent that the manual tasks of deploying infrastructure, keeping it patched, monitoring and the myriad other things a SysAdmin performs every day could not keep up with the demands of the increasing pace of the digital world and the onset of cloud computing. Infrastructure is moving rapidly to being automated and programmatically deployed and the talent needs to adjust accordingly to stay relevant.

With many enterprises adopting the agile methodology and moving toward a continuous integration/continuous delivery (CI/CD) pipeline, the culture of DevOps became a reality. Due to the increased velocity, there became a clear need for the core tenets of DevOps culture, which include culture, automation, measurement and sharing (CAMS). In Six Million Dollar Man terms, this was simply “Better … Stronger … Faster.”

Embracing DevOps through CAMS is similar to the superhuman enhancements that composed the rebuild of Steve Austin, which took him from man to bionic man. Here are the four ways that DevOps can increase your enterprise’s “bionic footprint”:

Improve Culture

Even Austin’s bionic features only got him so far; the bionic man had to rely on his team to complete his dangerous missions unscathed. The same is true in the enterprise: Building a collaborative culture is crucial for success. Culture is paramount in maintaining overall velocity without adversely affecting quality. Developers and operations teams need to function in concert to ensure a resilient application and infrastructure.

Increase Velocity via Automation

Automation greatly increases velocity, akin to how Austin’s bionic legs allowed him to run at high speeds and make great leaps. Automating processes saves time, money and lets your team focus on more complex tasks—a win-win for productivity gains.

Measurement

Steve Austin had a bionic left eye that enabled him to see in the dark as well as detect heat. This provided him precise measurements of his surroundings in any situation, enabling him to gain the upper hand against adversaries. Similarly, measurement gives insight into all aspects of the software development life cycle, application performance and other key metrics. Without insight and transparency into measurement, your team is essentially working blind.

Sharing

Austin had a bionic right arm that had the strength equivalent of a bulldozer. Strength and resiliency are increased by teams that work and communicate effectively made possible by DevOps.

To summarize, I strongly believe that the mantra of “Better … Stronger … Faster” should be that of every DevOps team moving forward. DevOps’ parallel of CAMS upgrades your team’s capabilities to perform more productively. There is no end game; the objective is about continuous improvement, velocity and sustainable growth. Enterprises that want to undergo digital transformation need to adopt this cultural approach to increase their “bionic footprint” to succeed.

About the Author / Mike D. Kail

Mike D. Kail is chief innovation officer at Cybric. Prior to CYBRIC, Mike was Yahoo’s chief information officer and senior vice president of Infrastructure, where he led the IT and global data center functions for the company. Prior to joining Yahoo, Mike served as vice president of IT operations at Netflix, where he was responsible for employee technology and various cloud engineering components. He has been widely recognized for his insightful industry commentary on social media Twitter, and was recently named by the Huffington Post as one of the “Top 100 Most Social CIOs on Twitter.” Connect with him on LinkedIn and Twitter.

January 26, 2017
Forecasting Culture: Sunny with Accumulating Collaboration

Bryson Koehler believes the most important enabling factor for DevOps success is culture.

Koehler is CTO of IBM’s newly formed Watson and Cloud Platform group. Prior to this role, he served as executive vice president, distinguished engineer and CIO/CTO of The Weather Company (TWC), an IBM business since 2016. He has a record of successfully leading significant business transformations and underlying cultural transformations, which he maintains in tech companies must be incited first at the developer level. As such, while at TWC Koehler built a DevOps culture and practice that encourages transparency, accountability and collaboration, and it is his mission to replicate the successful model in the transformation of IBM’s culture.

Since I experienced some of the TWC culture firsthand, I asked if he would be willing to share his thoughts on enabling a high-performing culture as well as maintaining that culture during periods of rapid growth or change.

He started the interview with a theme clearly central to his core ideology as a transformational leader, and one of TWC’s key factors for success:

Culturally, the goal is to find people who really love what they do. I want people to wake up in the morning and love what they do—not tolerate it, not like it, but love it. We work very hard to find people who love what we do and love the mission we are on. If you work very hard to assemble a team that loves what they do, the culture will take care of itself as long as you enable it … it’s about enabling them, with as much freedom and flexibility as possible, while still maintaining some level of consistency and control. It’s a balancing act and at TWC we worked very hard to give the right tools that enable people to work on any device, anywhere, at any time. The tools were an enabler; it was the culture that really invented itself based on the fact that we hired people who love what they do.

Koehler’s commitment to finding the right people with the skills and passion consistent with his company’s mission put the base focus of enabling DevOps practices where it needs to be—with the people.

For those that have read some of my other blogs, one of the things I’ve written about before is the mistake of choosing tools without first addressing the critical underlying aspects of DevOps including, a solid agile foundation and the cultural changes required to facilitate DevOps practices. Needless to say, Koehler’s comments about tools being an enabler really resonated with me because it was clear he still views the tooling as very important but puts the real emphasis on having the right people. The other key message that really resonated with me during the interview was his commitment to accountability and transparency:

… from a leadership perspective, it’s around making sure there is clear accountability. There is single-person accountability for work. If you walk into a meeting and you don’t know who the single decision maker is in the meeting, my recommendation to the team is to leave. Don’t have the meeting, because it’s a waste of time. There should be one person that everyone knows is the decision maker, whatever the topic. If we don’t know that, then it’s my job to make sure I make that crystal clear. You can’t walk into a meeting with five people all thinking they own the decision when also working to create a culture with high velocity, high throughput and high passion towards meeting objectives and getting stuff done. You hire people who love what they do, you enable them with great tools, you have crystal-clear accountability and decision-making so that things can get decided quickly and that we know who is accountable for making sure that decision was successful, and then constantly work against the goals of the business. You also have to be very willing to adjust your tools, very willing to adjust your people, and very willing to adjust your decision-making. We must be constantly willing to look at ourselves and figure out how we improve.

Koehler’s willingness to continuously look inward and adjust what is not working demonstrates another key success factor for high-performing DevOps teams. Having an executive driving that culture of continuous improvement is critical for DevOps success.

He also is dedicated to core agile principles that allow for flexibility and responsiveness while maintaining some degree of focus and clear prioritization. With the rapid TWC growth, we also discussed how he maintained and adapted the existing culture in response to that growth:

It’s really critical for me as a leader to stay very in tune with how these teams work and function, calling out any bad behavior and correcting it quickly. I’m just as willing to roll up my sleeves and get dirty as the next guy, and I expect everyone else to do the same. Kingdom building is not something that will get you very far in how we work. If you do that [roll up your sleeves], then as part of your culture, everyone puts down their guard and realizes that nobody is any more or less important than anyone else. We are all here to accomplish the same thing.

Common goals and people that love what they do! It’s a great mix and Koehler has some fascinating perspectives on driving cultural transformation in support of DevOps practices, not only for the efforts he successfully led at TWC but for the efforts he will continue to lead within IBM. His commitment to culture can best be wrapped up by one of his final comments:

None of our great technical ideas has any chance of seeing the light of day if we don’t get the culture right.

Thank you again to @brysonkoehler for the interview and insight into TWC’s amazing culture and your vision for IBM!

About the Author / Bryson Koehler and Shelbee Smith-Eigenbrode

Bryson Koehler is CTO, IBM Watson & IBM Cloud – GM & Distinguished Engineer at IBM Connect with Bryson on LinkedIn and Twitter

Shelbee Smith-Eigenbrode is a Senior Software Engineer/IT Architect at IBM and has been in IT for 19 years. She has worked across varying roles spanning the software development lifecycle. Her experience across functional roles as well as performing that work deeply inside traditional silos has contributed to her passion for embracing the DevOps culture and transforming the way teams are delivering technologies by adopting DevOps practices. She is a member of the IBM Academy of Technology as well as an IBM Master Inventor committed to driving innovation and technical advancement. Connect with me on Twitter @Shelbee_SE.

January 13, 2017
DevOps by the Book in 2017: Where we Really Stand

Now that the year-end prediction season is over, it’s time to focus squarely on the actual here and now—where the DevOps movement actually stands at the start of 2017.

As we’ll need to wait another six months or so for the annual State of DevOps Report to emerge from the good folks over at DORA and IT Revolution, which forces us to take stock of the situation using other resources. In this case, I’ll point to the recently released book, “DevOps for Digital Leaders,” authored by my colleague Aruna Ravichandran along with co-authors Kieran Taylor and Peter Waterhouse.

Register today for the upcoming webcast, “Chart a Winning Course: DevOps for Digital Leaders,” and enter the chance to win a free signed copy of the book [U.S. only].

Why should you value this book over any of the other DevOps-related titles inundating the technology literature scene, in particular those issued by (gasp!) technology vendors? I’d cite two very specific reasons: real-world metrics and use cases.

I often preview any comments I make in cross-functional meetings with the phrase “shameless marketing.” That is because I work in marketing. For 12-plus years prior and sometimes in between marketing gigs I’ve served as a journalist, wherein my job was to attempt to be as objective as possible. Today, I work for a vendor that would really like to sell you stuff.

That said, this current career path does not preclude me from being able to see beyond my own not-so-secret agenda. While many onlookers understandably groan and roll their eyes at the manner in which DevOps has been co-opted by marketers as a means to advance products, this doesn’t mean we’re all full of it.

Like myself, working at CA—in particular, leading marketing efforts that span a huge array of strategic technologies actively being leveraged by global enterprises to attack various elements of DevOps—has given Aruna and her partners tremendous insight into where many people stand in terms of maturity.

To that end, this book is written around some fantastic stories about how some of these organizations are refining best practices and measuring real success in domains including continuous testing, release automation and shift-left monitoring. IMHO, these are some of the hottest areas of DevOps being advanced as we speak.

In addition to these use cases and related practices, the book takes an up-close look at critical aspects of the DevOps build, test, deploy and manage stages, along with key processes related to tuning and continuous improvement. And it even goes so far as to talk about essential DevOps tooling. I hope people are ready to acknowledge that beyond culture and leadership, automation absolutely plays a significant role in all of this.

Specific to metrics, one of the areas where the State of DevOps peeps attempted to break new ground in the 2016 report, there’s a lot to appreciate. The book takes a close look at how these same organizations are attempting to tie DevOps-driven change directly to ROI, including the all-important customer experience.

Worth noting, in the coming days we’ll also see the release of a new report from Coleman Parkes that charts numerous KPIs being used to this same end, so stay tuned.

So there you have it, the marketer has officially hijacked this blog space to do little more than market a book about DevOps written by marketers. But, the truth is that’s not all.

If you really want to hear the best parts of this story, sign up for the upcoming devopsy.kinsta.cloud webcast, “Chart a Winning Course: DevOps for Digital Leaders,” in which Aruna and Alan Shimel will discuss the high points, with an emphasis on fielding questions from the audience live Q&A style.

If you don’t have time to read the book—or, better yet, you want a preview to ensure that what I’ve written here is true—post up and ask your own questions. We’ll also be conducting live polls about DevOps maturity, audience use cases and the leading types of DevOps metrics.

It’s worth noting that all proceeds from the print edition will go to Foundation for Excellence, which provides STEM scholarships to children in India. Order your own copy today (or download it for free).

— Matt Hines

January 12, 2017
Time, Training: How to Implement DevOps Effectively

Successful implementation of DevOps solutions requires two very important investments: time and training.

New technologies have always transformed how the commercial world operates. The steam engine for example, fueled the industrial revolution of the 18^th century and changed the face of business forever. This dramatic shift didn’t happen overnight, though; people had to learn new skills to manage steam power and operate trains, ships and equipment that previously did not exist.

Adopting a new system within a modern day organization is no less challenging. It takes in-house expertise and top-down leadership to crest the learning curve as quickly as possible.

Training Your People

To realize the benefits of DevOps, businesses need people—particularly, system administrators and their managers, who know how to operate the systems. It really is that simple, yet most companies just don’t have the skills. Training, training and more training, coupled with lots of hard work and practice, is paramount.

Middle managers in charge of integrating the new systems are first in line for training. They deal directly with upper management as well as with the new software’s end users. To communicate the importance of DevOps to both audiences successfully, they need to understand exactly what DevOps can achieve—and how to get it up and running in line with the company’s wider business goals. They need to know what skills are needed to implement DevOps companywide and identify the right people to learn the ropes quickly and efficiently.

Push from the Top

A successful switch to DevOps also is dependent on support and buy-in from upper management. They don’t necessarily need to have an in-depth knowledge of the systems, but they do need to push for fast and effective implementation—and allocate the resources to make it happen. With all key stakeholders working together to reach the same realistic timelines and deadlines, the new systems will be introduced far more seamlessly. If the process is at all disruptive, people will be reluctant to change their way of working and do things the same way they always have.

Senior management must support the system change and encourage its use across the organization by openly embracing its potential.

Test the System

Traditionally, implementing a new production system was a long, onerous process with lots of restrictions and administrative hurdles to jump. In many instances, a committee of key stakeholders was needed to verify and approve each step. Forms had to be filled out, a thorough backup plan would be prepared and a bureaucratic chain of command would be followed. The further removed from the actual implementation project each signatory was, the less committed they were—which often led to repetitive meetings and costly delays.

This labor-intensive change management approval process was in place to help prevent any failing in the production plan, which could have disastrous effects. Should for example, an online retailer’s check-out or internet banking infrastructure go down, business profits and reputation would suffer significantly.

Implementing DevOps is different. It uses a test environment to speed up the onboarding process and minimize errors. IT engineers can do dry-runs before going live to check how the new systems are integrating and if anything is wrong before it actually does go wrong. Bugs and glitches are fixed without impacting the current systems and the approval process is far faster and much more confident. All of which can speed the entire implementation process and its success.

The potential of DevOps is inextricably linked to the people who implement and operate the new systems as well as the old. To achieve the best possible outcome, your team needs to have the experience and skills to ensure a seamless integration that enhances core business functions without losing or disrupting the organization as a whole.

About the Author / Francis Miers

Francis Miers is a Director at Automation Consultants – Automation Consultants (AC) is an IT services and software company with a mission to improve the speed and reduce the cost of IT project deployment by implementing automation across the software life cycle. AC develops and deploys advanced software automation solutions. Customers include BskyB, HSBC, Invensys, Orange, EverythingEverwhere and Vodafone.

January 10, 2017
DevOps Leaders Share 2017 Reflections, Predictions
As the New Year kicks off, it is a time for reflection and a chance to look ahead and plan for what is to come. While many are making personal resolutions pertaining to their physique, job performance or travel plans, there is a lot of chatter in the software delivery space around what DevOps will look like these next 12 months.

Looking back on 2016, suffice to say it was a big year for DevOps. There was no lack of resources for those in any phase of a transformation, with global conferences touting its name to weekly (if not daily) podcasts and webinars designed to share the latest expertise with the community. However, as DevOps moves from buzzword to phenomenon, it will be held to even higher standards and scrutiny, becoming ever-more polished and perfected as challenges are faced and overcome. But don’t just take my word for it.

Electric Cloud recently hosted a live, online video podcast featuring notable DevOps luminaries discussing their own reflections and conjectures. The panel included Nicole Forsgren, CEO and chief scientist at DORA; Robert Stroud, principal analyst at Forrester; Chris Riley, analyst at fixate.io; Manuel Pais, author at InfoQ and SkeltonThatcher; Alan Shimel, editor in chief at devopsy.kinsta.cloud; Sam Fell, VP of Marketing at Electric Cloud; and yours truly. This article highlights 16 different insights from our discussion with these great minds in DevOps. Here’s to what has been, and what is to come!
- Expect to see a trend toward strategic DevOps transformations in 2017, according to Forsgren: “I think there’s going to be a huge trend moving forward to do really careful and strategic assessments about where you are, intentional prioritization and strategy about understanding what your constraints are, so that you can do strategic capabilities development moving forward.”
- Riley hopes 2017 will be the year we stop talking about DevOps and start doing it: “In 2017, we’re going to stop defining DevOps, and we’re going to hopefully use the word a lot less. We’re going to be real about what it is and getting it done. It’s going to be a lot less talk and more doing.”
- I emphasized that having good architecture in place is crucial to successful DevOps: “What’s starting to happen is that you’re going to have a really hard time doing DevOps well with a crappy architecture, whether that be a crappy architecture for your pipeline or crappy architecture for your application. Application architecture matters in your ability to do DevOps well.”
- Stroud emphasizes the importance of experimentation in DevOps: “Organizations [will] look to drive mainframe R&D in a DevOps methodology—not just mainframe development, but also supporting velocity in rolling it out to production, with organizations moving from one or two major releases a year, to now experimenting with both quarterly and monthly releases using DevOps practices and experimentation and techniques.”
- While tools and processes play a major role in a DevOps transformation, we must not forget to maintain a culture of empathy, emphasizes Shimel: “Have empathy for your fellow workers, empathy for your fellow humans. Don’t think because you’re the dev, that what you’re doing is more important than what the ops guy is doing.”
- DevOps certifications are the future, according to Pais: “I think we’re seeing more and more DevOps education and certifications. I know, for example, there’s an IEEE standard for DevOps being worked on.”
- Sweat the small stuff, advises Fell: “It’s never been truer than in this accelerated cycle that we’re seeing with productivity and all this awesome value being created from relatively minor, incremental improvements in process, in tooling, and all the stuff that we do, and the feedback that we’re getting.”
- I believe 2017 will bring major disruption in the FinServ community: “We will see some, hopefully, interesting disruption in the financial technology area, because the financial institutions have always treated technology as a key differentiator. Now, the problem they have is that their culture, by and large, sucks.”
- Some wise words from Stroud: “Strategy without execution is wasted time. We have to execute. We have to be prepared to fail. We have to be prepared to come and share our experiences.”
- Measure, measure, measure is Forsgren’s DevOps focus in 2017: “What’s going to be my goal is having all of us think about measuring in smart ways, so that we can actually do these experiments that are small, that allow us to fail, because big massive failures are scary, but those are the ones that are easy to measure with crap measurements. Because when you fail big, you know you failed big.”
- In 2017, we will see a breakdown of DevOps tools’ silos, per Shimel: “It’s really ironic that in something like DevOps, where the idea was to break down silos between dev and ops, dev and QA, and QA and security, but what we’ve done is we’ve built new silos of DevOps tools.”
- Pais on the trends he sees in early adopters of DevOps: “For the majority of organizations that have already been doing DevOps for a while, they’re now focusing on what’s the best way to organize teams. Moving, often, from having just specific people who know about continuous delivery, DevOps and so on, to actually getting platform teams that embed all the services that they want the development teams to use.”
- Oddly enough, development teams are still more likely to adopt DevOps than operations teams, explains Stroud: “One of the data stats we pulled has to do with DevOps adoption in development versus operations. Isn’t that ironic? Because the name DevOps is dev and ops. We still see significantly more DevOps adoption in development than operations, but the good news is the gap is closing, based on the Forrester data.”
- Containers will continue to be a major player in 2017, says Riley: “Where I believe there will continue to be growth is container-native tooling, container-native security and container-native release automation.”
- The reality is, there are still a lot of organizations not doing DevOps, remarks Fell: “We are living in this bubble, happy bubble, of everybody gets DevOps and we’re all Agile. But we talk with folks that we talk to who are just like, ‘Yeah, we do nightly builds, and we’re really looking forward to doing continuous integration.’ Your jaw drops, like, ‘Wow. Yeah, that’s a good idea. You should do that.’”
- And, finally, I share some sage wisdom to keep in the back of our minds: “If what you’re doing on any given day isn’t moving that ball forward, what is the point? I think we need to focus a little more on that.”
Bonus 17^th quote for 2017, from Shimel: “I think the story of 2016 is DevOps has gone mainstream. We’re seeing pockets of DevOps come together as bubbles, but we still have the majorities in front of us, going forward.”

For more reflections and predictions, watch the full episode:

About the Author/Anders Wallgren

Anders Wallgren is Chief Technology Officer of Electric Cloud. Anders brings with him more than 15 years of in-depth experience designing and building commercial software. Prior to joining Electric Cloud, Anders held executive positions at Aceva, Archistra, and Impresse. Anders also held management positions at Macromedia (MACR), Common Ground Software and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7 and various Shockwave products. Anders holds a B.SC from MIT. Connect with Anders on LinkedIn or Twitter.
January 10, 2017
Customer Demands Outpacing Business Requirements

As more organizations adopt agile and DevOps, many recognize quickly that the related gains are significant but further business efficiencies can be realized.

IT and the business now are working closer than ever. No longer is the business throwing requirements over the wall into the IT “sausage factory”—they’re now an integral part of the entire process. IT has finally transitioned into a profit center.

In the application economy, it’s not the layout or cleanliness of your brick and mortar store nor the friendliness of a customer service representative that makes your business successful. It’s the application’s user experience.

As a result, the gains we’re seeing must be optimized continuously. One of the biggest challenges we face today lies in how we get business requirements translated into IT output, at the speed of business.

In the old days, it was easy to move your best-selling, highest margin products into the ideal location or open another checkout when the lines got too long. With today’s virtual stores, the question becomes, How can we quickly pivot to tend to our real-time customer needs and shareholder expectations?

We must be able to deliver software faster, and to do that, we need to marry our strategy to execution and delivery. We must optimize across the entire business to create true agility that paves the way for reactive and proactive acceleration.

Case in point: If you optimize execution but not delivery, you’ll be creating software that cannot realize value at the pace of development. In reverse: If you optimize delivery but develop software slowly and poorly, your efficient delivery process will merely sit waiting—or worse yet, deliver poor quality software quickly.

As a result, we must optimize all three of these areas while working in conjunction, overlapping and providing constant feedback and properly timing the impact of revenue and potential risk to customer experience.

Unsurprisingly, to support all of this, we’re also seeing broader adoption of an end-to-end solution stack that supports acceleration of process from ideation through outcome. Let me walk you through this scenario:

Your business is managing your strategy through the lens of its portfolio. As changes are set in motion at the highest levels, that data must be tracked—how much it costs to implement new functionality, how much time it should take and what ROI looks like—along with constant reviews to inform ongoing decision making.

Your portfolio decisions are then loaded and tracked systematically at the project level, with resources assigned systematically to deliver the designed functionality through epics and user stories. Related data must also be made available in real time to be viewed at the program, project, epic or user story level, providing complete visibility from the level of developers all the way up to the board of directors.

Simultaneously, your user stories must be imported into a system that turns them into test cases and test automation assets, then builds the test data synthetically to validate each test case. Once the data is generated, it’s imported into your service virtualization system, where application behavioral virtualization eliminates the need for constrained and non-existing back-end systems, simulating an end-to-end environment for any application that is being tested. This also should update your virtual services automatically with the data required for the test cases and any planned test automation.

Let’s pause and review what we just did.

We’re now managing our new functionality items across portfolio, program, project, user story and resource levels, all in real time. We’ve automatically created our test cases, test automation, test data and virtual services, all from the epics and user stories.

So what have we done? We’ve provided the visibility and insight necessary to make business decisions in real time and track progress. We’ve also also minimized the need for test-case designers (or the business analysts that create them), test automation engineers, test data engineers and the DBA support for test data, freeing these experts to focus on other activities.

Hopefully, we’ve achieved the desired result of massive reduction in resource allocation, acceleration of the entire software development life cycle, elimination of error-prone manual tasks and, most importantly, elimination of the ambiguity involved in translating actual requirements into test cases.

Finally, we’ve now got all the necessary elements—team execution, prioritization by value, connection of value to execution, a platform that provides a single source of the truth, communication, and metrics—that will allow you to focus on creating value for your customers, instead of simply creating process.

Transformation is difficult. Culture/environment eats process for breakfast. However, by focusing on changing your entire approach instead of merely recasting process and teams, you can truly change how you provide value to your customers and shareholders.

This is how we translate business requirements into innovative software at speed.

For added perspective on all things DevOps and Continuous Delivery, join my colleague Aruna Ravichandran for a live webcast highlighting the details of her new book “DevOps for Digital Leaders”—it’s sure to be an exciting discussion.

— Ron DeCanio

January 5, 2017
DOES San Francisco 2016: Adrian Cockroft On Retaining Talent

Another one of the over 50 video interviews we did at DevOps Enterprise Summit 2016 is our discussion with Adrian Cockroft. Adrian is was one of the last presenters at DOES this year, but that was a good enough reason to stick around until the end. Adrian’s presentation was on the challenges in retaining talent at high tech organizations.

Before we dive into the talent conversation though, Adrian talks a bit about his own journey from Netflix where he pioneered so much of what we see in the DevOps market today. After Netflix, Adrian joined Battery Ventures, where he had the opportunity to go visit with numerous large organizations and find out what was working for them and what their challenges were. He was able to use that information to help guide Battery in which companies they should invest in to add to their portfolio. After several years at Battery, Adrian has recently left to join AWS where he will once again be directly involved as the VP of Cloud Architecture.

But as I said earlier, Adrian’s presentation (truth be told he only had one slide or so, it was more of him speaking) was about the lack of enough qualified people to fill the ranks. This pressure results in successful companies having to “grow” their existing talent. But as Adrian points out the very act of letting this talent grow also leads them to move on. As they become more prominent in the field they are more likely to be recruited away. So how do you retain talent? Adrian tells us some of the things Netflix did to keep their engineers. Of course what Netflix did does not translate to many traditional organizations though.

Obviously, monetary compensation helps an awful lot. But there are things beyond money (sometimes). Things like giving people titles like distinguished engineer for example.

Adrian also brought up the example of Brent in the Phoenix project. How by giving him a different role, you not only remove the bottle neck, but also keep him happy in his new role.

As usual, it was great listening and learning from Adrian. His reputation as one of the leading lights in the DevOps space is well earned and well deserved. Enjoy the conversation!

You can see over 50 video interviews we did at DOES 2016 on our YouTube channel, DevOpsTV.

— Alan Shimel

November 17, 2016
‘Best’ is Relative, but Starts at the Top

Your aging mom needs a new car. You are picking it out for her because she quit paying attention to cars long ago. All you ever buy is Fords. You also always buy trucks. Do you pop off and buy your Mom an F350? Not unless she actually needs an F350 (highly unlikely, but aging moms are as varied as any other group of people, so maybe). Why? Simply because you are buying a vehicle to solve a problem: Your mother’s need for a new car.

Ford F350

Setting the parameters of decision-making is the CIO’s role. Or at least a part of it. IT has struggled with justification since its inception. Far too often we are justifying choices that are made before justification is carried out. Browser wars, OS wars, language fights … all have marred IT practically from the day that an IT staff became necessary.

The fact of the matter is that people have preferences, and organizations do, too. If you have 300 instances of Oracle database running, you have investment in staff, training, licenses, etc. that you can reuse if Oracle is a choice on the next project. Contrast this with “the next project” containing a purchased package that only works with SQL Server. The two are natural tensions that need to be figured out.

In far too many cases we zero in on what an individual thinks is best or “right,” and not on the needs of the organization across projects. On the development side, Agile has made this more of an issue than it has been in a long time, maybe ever. Simply put, the faster the better is the rule for Agile, but long-term ramifications of that approach can be large. If internally developed apps vary from NoSQL to SQL server to Hadoop to Oracle and you’re having to maintain all of the above, both in Ops and in Dev, you may have delivered quickly, but the accrued cost—call it the mortgaged technical debt—can be expensive over the long term.

And the way that we end up with multiple solutions to a given problem is by allowing champions to drive their point home in a vacuum. While it is great when an employee says, “I know a [needed library, tool, app] that will solve this and I can have it running in a day,” there is a larger picture that needs to be considered.

DevOps definitely gives us the opportunity to review these choices and put a stake in the ground. Sometimes the internal champion is right, and that’s the tool to use in this scenario. Sometimes they’re not, and an already implemented tool/library/app should be used. But the conversation needs to happen.

I wrote about some of this back when I worked for F5. It was amazing to me the number of customers who purchased F5’s very expensive gear, then set it up as a load balancer and went looking elsewhere for WAN optimization or security solutions, when the BIG-IP could do the job. That’s a good example of waste, but just the tip of the iceberg.

When implementing DevOps on the Ops side, take a look at what you have. If you’re writing the same script for three different targets, it is probably time to go find out why. The reasons might be perfectly acceptable, but they might not be. If purchased apps really only support one product for AAA, then that product is probably required, even if it means propagating logins across to the corporate standard AAA tool.

But the process to make certain these decisions are being made intelligently, with a focus on standardization but adaptability to handle exception cases, is driven from the top. Stressing that first choice is X, but Y and Z are acceptable alternatives for projects of priority three and above is important. Stressed from the top it says, “We have standards, and we all need to try to adhere to them to keep workloads down as much as possible, but we have a business to support, and will make exceptions where business value is added.”

It’s not always easy. Not politically, and not technologically. Sometimes the solution available internally isn’t a perfect fit for a given problem, but long-term, the work required to make it solve the problem is less than the expense (in duplicated expertise and licensing fees, let alone duplicated DevOps scripts) to drop an easier solution in. IT staff are smart folks and fully capable of making those decisions, but the direction to do so must come from the top. Without it, some will aim for standardization over speed of implementation, some the opposite. Inevitably, many will aim for what is easiest for them.

I have worked in two industries where data went from paper in filing cabinets to microfiche to mainframes to client/server to virtualization and/or cloud. Don’t assume what you’re doing only matters for now. Make the rules, ask the tough questions such as, “What do we have in-house that could fulfill this function?” and expect honest answers.

And if you’re going to do calculations such as TCO or ROI, make sure the team knows you want the numbers to lead to the solution, not the other way around. Because we all have seen the case where the solution changed how the numbers were calculated, and that just wastes everyone’s time.

So step up, Mr. CIO. Get Mom the Focus or a Honda—whatever will suit her needs. Not what you’ve always done, and not what is easiest for you to do. Set the rules so the team knows what decision criteria are, and make them clear so there is no miscommunication. And finally, give your DevOps team the room to make consolidation recommendations. If they’re seeing duplication of effort, let them call attention to it, and have a process to resolve their concerns. In the end, a simple, “No, that duplication is necessary because of X,” or “Yes, we should consolidate,” needs to come out of that process for each recommendation they make.

And if your Mom is that one that drives an F350, send me a picture of her by the truck. I’ll talk to the editors about getting it posted.

— Don Macvittie

November 1, 2016
To DevOps Or Not To DevOps

Although enterprises today all claim to be software companies, there remain four distinct groups of organizations: the technology leaders, the technology followers, the technology hopefuls and the technology laggards.

The first group are the industry leaders who are paving the way. These are the organizations coming up with new technologies, processes and cultural shifts. They write articles and books and present at conferences, and despite perhaps working at smaller companies, they are the names you may recognize. These are the companies the rest of us aspire to be—the Googles, the Amazons and the Microsofts that keep the rest of the industry hanging on to every word.

The technology followers typically are smaller organizations that tend to adopt the latest and the greatest technologies. They are the leaders’ first wave of followers who are not afraid to try new things, nor afraid to fail. They have cultures that allow them to experiment and adapt and are given a lot of free time to invest in learning and implementation, after they watch the big guys successfully implement.

However, the first two groups are the minority of software organizations, since not everyone can lead the way, nor can everyone have the luxury of spending a significant portion of their time experimenting with new methods. After all, most of the new technologies do not have a long lifespan. They appear, generate some attention and then disappear. Front-end frameworks provide a great example of this: new ones pop up and exist for a few months before being superseded by other frameworks.

Another example of technology followers is containers—few doubt their usefulness and most of us are convinced they are the best solution. The only question is which cluster orchestration framework to choose. These frameworks are evolving so rapidly, with new ones introduced on a weekly basis, that it’s almost certain most will be defunct within a year. So, if you are into experimenting with the latest offerings, chances are you could make a wrong choice. Will it be Kubernetes? Docker Swarm? Mesosphere Marathon? Rancher OS? Cloud Foundry’s Diego? CoreOS Fleet? The question is not whether to adopt one of those tools, but rather, which one has the best shelf life.

Most of us fall under the third group, the technology hopefuls. We don’t have the ability to lead the way, nor do we have the luxury to explore the latest and greatest technologies. Yet, we cannot allow ourselves to become obsolete. The industry is moving so fast that just a few years can leave you at the back of the pack where no effort or investment can get you back in the game.

The technology laggards are the software companies that have fallen behind. This group includes businesses that are struggling to remain intact and run the risk of disappearing. These are the organizations that do not innovate, do not adapt, do not invest (enough) in improvements and do not even understand the current industry trends. They are the organizations that do not comprehend that becoming obsolete doesn’t take decades, but years—sometimes even months.

Based on the definitions of these groups, chances are, unless you are Google or Microsoft, you are not in the first or even second groups. By reading this article you are making the effort to be informed so you don’t lack the self-awareness that places you in the fourth group. Like most software organizations, you fall into the third group of technology hopefuls.

As part of this group, you have to balance between the latest and the greatest technologies and the chance of becoming obsolete. You cannot try every new solution that comes along, nor you can let years pass by until you jump on the train. The big questions you have to ask are, How can I distinguish what will stay and what will disappear? How do I make a choice between what to adopt and what to ignore?

There may not be a one-size-fits-all answer, but one process you absolutely cannot ignore is DevOps. If you’re asking yourself whether your organization should adopt DevOps, the answer is a resounding “yes.” And I encourage you to adopt it now, before you are replaced by other companies that are already living and breathing DevOps. Otherwise, you’ll be unable to adapt to the speed needed to keep up in today’s market and understand the cloud and scale accordingly when an avalanche of users come to your site after a successful marketing campaign. Lacking preparedness could cost you your business, especially in a competitive market.

DevOps is here to stay, evolving similarly to Agile by providing value and answering many of today’s challenges. The only problem is that adopting DevOps can be difficult. To implement DevOps, you might have to change your company’s culture; you might need to adopt new tools; you might need to change processes; and, you might need to change your software architecture. Changing any of those aspects is hard, but changing all of them is very hard.

Your culture and company structure need to be agile (in the literal meaning of the word). The old, monolithic tools need to be replaced with smaller, much more dynamic ones that will work well with the ever-changing nature of cloud infrastructure. Processes need to be automated, since there is no time to pause for manual intervention. To accommodate the needs of automation and frequent deployments, your applications and services will need to be relatively small for continuous delivery or deployment to become a standard process. Your teams need to be highly specialized and fully capable of working on all aspects of the software development life cycle, from requirements to post-production support.

It’s a harsh and challenging road ahead, but at the end of it lies success. You’ll experience faster time to market, greater reliability, high availability and faster adaptability to market changes. Some are already there, while others already embarked on the journey. Don’t be left out—the alternative will leave you obsolete.

To DevOps or not to DevOps is not the question. For most organizations, adopting DevOps is the answer.

About the Author / Viktor Farcic

Viktor Farcic is a Senior Consultant at CloudBees, a member of the Docker Captains group, and books author. He coded using a plethora of languages starting with Pascal (yes, he is old), Basic (before it got Visual prefix), ASP (before it got .Net suffix), C, C++, Perl, Python,ASP.Net, Visual Basic, C#, JavaScript, Java, Scala, etc. His big passions are Microservices, Continuous Integration, Delivery and Deployment (CI/CD) and Test-Driven Development (TDD). He published “The DevOps 2.0 Toolkit: Automating the Continuous Deployment Pipeline with Containerized Microservices,” and “Test-Driven Java Development.” He is currently working on his third book, “The DevOps 2.1 Toolkit: Docker Swarm.” Connect with him on Twitter.

November 1, 2016