Tag: adoption

DevOps is Dead! Long Live DevOps!

Some are seekers on the quest for the one, true DevOps. They were misled. I’m here to say: Give it up. Whatever you find at the end of that journey isn’t it. That one true DevOps is dead. Dead and buried. The search is pointless or, kind of worse: The search misses the point altogether.

DevOps began as a sort of a living philosophy: about inclusion rather than exclusion, raises up rather than chastises, increases resilience rather than assigns blame, makes smarter and more awesome rather than defines process and builds bunkers. At any rate, it was also deliberately never strictly defined.

In 2010, it seemed largely about Application Release Automation (ARA), monitoring, configuration management and a lot of beginning discussion about culture and teams. By 2015, a lot of CI/CD, containers and APIs had been added. The dates are rough but my point is: That’s all still there but now DevOps discussions today also include service design and microservices. Oh, and the new shiny going by the term “serverless.” It is about all of IT as it is naturally adapting.

And this emergent, inclusive content is possible because it’s always just people talking practices and sharing how to optimally do things. Infra as code, “cattle, not pets,” webscale, version and automate all the things, horses not just unicorns, etc. Lots of conversations, insights sharing, presenting.

Good times.

There are more DevOps Days naturally occurring globally this year in 2017 than ever before. Note I wrote “naturally”—DevOps was always an organic movement, a grouped (and, whoa, global) response to increased app release pressures and the desire to select for teamwork over turf wars.

So we started with DevOpsDays and those blossomed all over. Then we got the Phoenix Project, the DevOps Enterprise Summit (now in US and EU formats!), and more great books including “Infrastructure as Code,” “System Reliability Engineering” and, finally, “The DevOps Handbook.” It’s all solid, informative stuff and I believe as a community we’re smarter, happier, and far more effective because of it.

Even those naysayer analysts—you know who you are—have come around to accepting the DevOps goodness.

DevOps lives when we continuously adapt to managing emergent properties spawning system-level feedback loops in our IT and across our businesses. To do better, faster, higher quality things to delight the customers.

Any discussion of DevOps is truly about continual IT innovation adaptation because the rate of IT change is also changing. Fast and faster. All that means starting with the roots like CLAMS and moving forward with containers and embracing the journey to quickly delivering better customer experiences.

So, the concept of DevOps is evolving, just as our understanding of what’s needed is evolving.

— Christopher Little

March 7, 2017
Is Cloud Adoption on Your Company’s Horizon?

Under pressure to increase the speed of innovation in the digital space and outpace competitors, companies large and small are turning to the cloud. Moving to the cloud provides flexibility of infrastructure, transparency of infrastructure costs and many other benefits.

However, making the transition to the cloud is far more intricate for regulated industries—especially large financial organizations—where security and compliance concerns often trump innovation efforts. According to Cloud Security Alliance, the financial industry is still in the early stages of cloud adoption. In fact, 61 percent of financial leaders say their cloud strategy is in the formative stages. Those financial companies that can shift to the cloud properly will see long-term gains, from both a performance and economic standpoint.

In 2015, while working at a large international bank, I assisted on a project to help transform how the bank approached digital for retail banking and wealth management. The bank was still approaching most projects as large, monolithic endeavors, where six-month delivery cycles were standard. Infrastructure was owned by IT Operations, and provisioning lacked automation. As such, almost every project began with designing environmental needs from scratch—adding time to both creation and delivery. It was quickly evident that cloud was the bank’s best option, allowing for increased transparency, greater scalability, infrastructure on demand and improved organizational efficiency.

Shifting to the Cloud

After working on this project, I learned that to effectively move to the cloud, organizations must understand how to maximize benefits and minimize risks. Here’s how:

Apply a two-pronged approach

We realized right away that we needed a system where we could meet our project objectives, while simultaneously exploring the cloud options. To avoid jumping in too quickly and running into non-technical challenges, we adopted a two-pronged approach: we’d build the platform internally using Cloud Foundry PaaS, while exploring the use of external cloud in parallel—without impacting the delivery of the internal platform. To avoid re-architecture and rebuild later on, we had a guiding principle: Whatever is built internally has to be available in the external cloud as well.

Navigate legal and compliance hurdles

Regulators are still on the fence when it comes to certain industries adopting the cloud, with regulations still lacking specific policies. For example, in the financial space, lack of close regulation leaves many institutions on their own to sort out contracts with cloud providers based on their individual risk appetite. When regulations are published, they are very high-level and generally state that managing the risk and responsibility for integrity of data is with banks, not with cloud providers. Instead of creating an equal playing field, this tilts the scale toward smaller fintech partners with larger risk appetite±and who more regularly fly under the regulator’s radar.

Expect roadblocks

In so many organizations, IT operates in silos. For example, all infrastructure is owned and operated by the IT Operations group, which then recharges that infrastructure back to the businesses based on complex metrics. For cloud to succeed, we need to answer the question of ownership. But that’s not all: Many folks may not believe that organizational issues are a serious problem, and thus, will lack a commitment to be involved. To ease this problem, strong sponsorship from senior leadership is essential.

Prepare for technical issues

When implementing a technology solution, things don’t always go smoothly from the start. For example, there might be approved ways to connect with third-party providers that were created before cloud providers came into play. While this kind of issue is easy to solve, it requires a change in internal procedures that must be accounted for.

Focus on development and testing first, then on production

While working toward final approval and negotiating the agreement, which can take significant amount of time, conducting a trial run is an effective way to work out any potential problems before full implementation. Signing an agreement to use cloud for development and testing only is less of a hurdle, as no customer data will be transmitted or stored. It’s also important to train anyone who might be involved throughout the process—no matter how big or small their role.

Conduct a formal project launch and set clear goals

To drive continuous improvements, it’s essential to establish clear objectives and goals. This provides metrics for benchmarking success and ROI, and encourages the brainstorming of new ideas on a case-by-case basis. Prior to the formal launch, don’t forget to identify key stakeholders and advocates—they will stand behind the project and provide valuable insight into the potential outcomes of decisions.

Create a transparent culture

Full transparency is key, even if it means dealing with resistance. Resistance, especially early on, often is unavoidable. However, it is better to deal with resistance, gain support and handle any issues early in the project. Being transparent gains you more support. Or, if the opposition is insurmountable, you can stop the project before wasting too much time or effort. Most important, you want to avoid criticism suggesting that the project is putting the company at risk. By looping in the right people from the start, you’ll have advocates in your corner who will raise red flags and anticipate problems on the horizon.

Remember that people will want to be involved

While cloud may still be an unfamiliar concept for many, almost always someone will come out and say, “Actually, I have experience, and already thought about how to do this. How can I get involved?” Bring those people on board, leverage additional insights and increase commitment to the project. This is an exciting change—people want to be on the team that introduces it!

Large, regulated companies historically have been slow to implement the cloud, due largely to perceived compliance concerns and security risks. However, in an environment marked with rapid innovation, companies are quickly realizing that to stay ahead, adopting a cloud-first business model is a must.

About the Author / Alexander Kalinovsky

Alexander Kalinovsky is Director of Engineering at Wipro Digital. He is a senior IT leader with extensive experience managing successful application development and operational teams, along with establishing global development practices and partnering with global organizations. Alex has spent over 10 years working in Financial Services in development and infrastructure, specializing in payment systems and FX solutions. Alex brings his strong FS background and enthusiasm for Agile development to his role at Wipro Digital, driving the digital transformation agenda for many of the world’s leading brands.

February 15, 2017

The State of DevOps Adoption and Trends in 2017

DevOps has come a long way, and we see a tremendous increase in adoption in the recent years. To outrank your competition and be ahead in the growth curve, it has become an essential element for software-powered organizations. DevOps has taken a center stage in the software development field with no signs of leaving.

Below is an infographic of DevOps and some of the trends we see happening this year in DevOps:

Sources:

http://www.rightscale.com/blog/cloud-industry-insights/new-devops-trends-2016-state-cloud-survey

https://www.storybase.com

slideshare.net

https://en.wikipedia.org/wiki/DevOps

Google.com

7 DevOps Trends

DevOps will be the mainstream and garner a lot of attention; hence, 2017 is going to be the “Year of DevOps.”
Along with DevOps, the three C’s—Continuous Integration, Continuous Deployment, and Continuous Delivery—are going to gain a huge momentum.
A number of new DevOps automation tools will be released that change the way we do software development.
“Containerization” also will be in the limelight.
Many software firms will move to a microservices architecture.
Automation and continuous testing will become more popular—and more important.
Must-have tools and platforms including Docker, AWS, GitHub and JIRA will become even more popular within developer zones.

The Names to Know

Below are the names of the top DevOps experts you need to follow:

Name	Twitter Profile	Who is He/She	Klout Score	Website
patrickdebois	https://twitter.com/patrickdebois	bridging the gap between creativity and technology with a #devops mindset; eternal researcher and pragmatic implementor; cto @townheroes; started @devopsdays	50	http://www.jedi.be/blog/
Avi Cavale	https://twitter.com/avinci	ceo @beshippable, wildlife photographer, scotch lover	50	https://app.shippable.com/
Kris Buytaert	https://twitter.com/krisbuytaert	Everything is a Freaky #Devops Needs Sushi Problem, Open Source, Infrastructure as Code, Consultant, Speaker, Author, Organiser of #devopsdays, #cfgmgmtcamp	53	https://about.me/krisbuytaert
Gene Kim	https://twitter.com/realgenekim	DevOps enthusiast, The Phoenix Project co-author, Tripwire founder, Visible Ops co-author, IT Ops/Security Researcher, Theory of Constraints Jonah, rabid UX fan	64	http://www.realgenekim.me/
Jez Humble	https://twitter.com/jezhumble	Co-author of Continuous Delivery, Lean Enterprise, DevOps Handbook; CTO devops-research.com, lecturer @BerkeleyISchool. PGP: https://keybase.io/jezhumble	63	https://continuousdelivery.com/
Gareth Rushgrove	https://twitter.com/garethr	Software developer, occasional sysadmin, general web, programming and technology geek and curator of Devops Weekly. Engineer at @puppetize. @gdsteam alumnus	56	https://www.morethanseven.net/
Denise Dubie	https://twitter.com/ddubie	Strategic Content Creator @CAInc, editor/writer/techie focused on App Economy, DevOps, Mobility, ITSec.& Mgmt., Cloud; former Network World/IDG tech journo.	50	https://www.ca.com/us/rewrite.html
Sanjeev Sharma	https://twitter.com/sd_architect	#DevOps #Agile #Cloud #TechSales #CTO #Architect #Author – #DevOpsForDummies #Blogger #Inventor #Disruptor #IBM #DistinguishedEngineer.	52	https://sdarchitect.blog/
Donnie Berkholz	https://twitter.com/dberkholz	Research director for development, DevOps & IT ops @451Research. PhD biophysicist. Open-source OG. Emerging tech, craft beer, and zeroth-world problems	59	https://451research.com/analyst-team/analyst/Donnie+Berkholz
Nathen Harvey	https://twitter.com/nathenharvey	VP, Community Development at Chef	57	http://nathenharvey.com/
Damon Edwards	https://twitter.com/damonedwards	DevOps, IT operations, and improving how businesses operate is my thing. Rundeck is where I work.	49	https://www.rundeck.com/

We hope DevOps will be a rock star in 2017 and continue to rule the software industry.

— TeamShippable

February 10, 2017

Overcoming Objection to DevOps Adoption

The advent of the application economy has made software arguably one the most critical and valuable assets of organizations across a broad spectrum of industries—financial, telecommunications, entertainment, and government, just to name a few. In the era of “app store ratings” and an unprecedented ability of the consumer to easily switch suppliers of whatever they’re consuming, delivering application feature updates as quickly and as safely as possible while maintaining high quality is absolutely critical.

Most of us with a pulse in the IT world are aware that the concepts and practices we know as “DevOps” and “continuous delivery” continue to dominate the software delivery conversation in IT organizations everywhere. Almost every business my company works with has some sort of continuous delivery or DevOps initiative in flight (with, naturally, varying degrees of maturity and success). And yet, we frequently encounter organizations where these ideas are anathema to many within, are considered overhyped buzzwords from consultants and vendors or, most frequently, simply do not apply to their organization in meaningful way. Others maintain that they have tried and failed so it’s back to business as usual. Many are swayed by a number of DevOps “myths” that often stop initiatives before they even get started. So, what is the objection over and some myths about DevOps that keep some organizations from taking the steps to improved software delivery? We’ll take a look at a few that we have seen firsthand and, in subsequent posts, suggest some ideas and strategies for getting past them.

Objection: “DevOps may work for some greenfield apps or startup but that’s not us.”

Many of our most reluctant customers acknowledge the benefits of DevOps and continuous delivery but maintain that their systems are too old, too monolithic, mainframe-dependent, etc., to reap any tangible benefits from a transformation. In other words, “it doesn’t apply here.” This point of view is especially frustrating because the benefits to organizations like these can be just as dramatic and transformative to the culture and IT “psyche” as found among the “unicorns.” Maybe even more so. As the 2015 “State of DevOps” study stated, “It doesn’t matter if your apps are greenfield, brownfield or legacy—as long as they are architected with testability and deployability in mind, high performance is achievable.”

Sometimes these groups will look to hybrid strategies such as bimodal where greenfield projects, innovation labs and other internal IT incubators are chartered to use new technologies and methodologies such as DevOps while the rest continue on as always. Opinions differ here, but these strategies generally are fine as a “way station” within an overall transformation road map with the potential to impede progress if accepted as the status quo. If legacy applications still change with some frequency and if deployments are painful for those involved, then those, too, should be included in the DevOps road map. We’ve done it at my company, a 40-year-old software company, and our mainframe team led the way.

Objection: “We are doing fine as we are.”

Another common category we encounter is the sense that, after some measure of improvement, perhaps the successful adoption of a toolset, that we’ve done enough. Things are better than before, our deployment pain has diminished so we have accomplished what we set out to do. A corollary to that is “we’ve implemented [Jenkins/Chef/Puppet/Cloud/etc.]” implying a belief that implementing one or more of these tools is, in effect, “doing” DevOps.

Successful DevOps is not about adopting a tool or even making measurable progress in organizational goals. DevOps is actually about embracing a culture of continuous improvement, collaboration and, perhaps most importantly, focusing first on maximizing value for your customers. It’s about adopting patterns such as the Deming cycle—Plan, Do, Study, Act—as a core tenet of the way you approach how you think about what you do. No matter what we do, no matter how well we do what we do, there’s always an opportunity to do better.

Objection: “Implementing a major change like continuous delivery is simply too large and complex an undertaking.”

When large, well-established organizations seek to undertake a major change, it’s often a task so daunting, so frequently met with skepticism and cynicism across the spectrum of stakeholders, that the initiative, no matter what it is, appears doomed from the start. Couple that with the culture-shift generally required to affect a successful and genuine DevOps transformation, and it’s no wonder that some senior IT leaders either severely limit the scope of these initiatives or, in some rare instances, veto DevOps outright. Regardless, the belief that their teams are too entrenched in current methodologies to make meaningful progress and the seemingly overwhelming weight organizational inertia stops change cold.

Transforming organizations that have functioned in, more or less, the same fashion for years, even decades in some cases, is practically incomprehensible for many. Organizational cultures generally evolve over time and changing them is not something that can be accomplished by decree and certainly not overnight. The barrier to even starting is often the sense that “we have too much work to do right now and balancing that against some intangible future state is not something we can take on.” Of course, the problem with that line of thought is that there will always be too much work to do now.

And, of course, there are many other obstacles. Barriers to entry against meaningful transformation like DevOps frequently emerge when new ideas and thinking collide with the status quo, especially pre-existing processes governing the software development and deployment. These processes generally emerged from the best practices of the recent past coupled with reactions to major problems encountered years ago that linger on as faint echoes of bygone errors. Most of these rules were put in place with good intentions, applicable at the time of implementation but may have outlived their relevance. Others may be regulatory and not optional. Regardless, if there ever was an area where DevOps and continuous delivery can deliver benefits, this is it.

Many large “traditional” IT shops have, indeed, transformed their culture and fostered environments that continuously improve. So, what do you do? Perhaps the most important step is to decide to take the first step. First, understand why you are seeking to change in the first place. What is the ultimate driver and does everyone, top to bottom, the organization have a clear understanding of that “why”?

Recognize that transformation is an ongoing process where successes and failures are to be expected in equal measure. Learn from both. Don’t attempt to roll DevOps out as a big bang strategy. Work incrementally.

In upcoming posts we’ll explore some strategies for moving past objection and making real strides toward meaningful and lasting change. What are some of the challenges you have faced in your company’s transformational journey? How did your teams get past the obstacles that inevitably appear?

— Jeff Bradley

December 9, 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
Engaging Adoption of DevOps
Executive mandate does not immediately translate into a change in behavior. Organizations inherently grasp the value of embracing DevOps, but the timing of exactly when it begins and is completed is another matter. The devil truly is in the details—or rather, in the ability and willingness of the organization to adopt a change in thinking and a change in the actions that follow.

“Adoption” is then a common term to describe the measurement of how far along an organization is in its transition between legacy and future, between the beginning and the completion of embracing DevOps services. As you might guess, adoption does not happen overnight, nor does it occur because of mandate or willingness. These factors influence the speed of adoption in some cases, but can act as deterrent in others. Adoption—like most other services provided to a given organization—occurs because its value proposition is sufficiently defined and resources are budgeted and assigned to it.

The level of resources you dedicate to tracking and facilitating adoption of DevOps in your organization is directly proportionate to the complexity of your development efforts. If for example, you have a new development team well-versed in cloud technologies and comfortable with using software-as-a-service (SaaS) tooling with only few applications under development (small app portfolio), your proportionate adoption efforts will be small, and transition should occur very quickly. However, if you have a large number of applications spread out across a wide variety of hardware platforms and are using a wide variety of development languages or tools, your proportionate adoption efforts will be far more substantial to keep the timeline manageable. In either example, a complete lack of attention to adoption results in elongating the timeline two to eight times longer than it would have been if formally engaging adoption was considered.

Adoption Engagement 101

So what do these adoption/engagement resources do from day to day? The primary focus of the folks assigned to this duty breaks down into three major categories of work efforts:
1. Communications conduit: The first responsibility of the folks on this team is to develop and implement a communications plan to keep all stakeholders up to date on what is going on with DevOps services. This includes metrics-based information such as how many applications have been fully onboarded to DevOps. It also may include how many applications have been onboarded into a particular level of automation within the stack, from code to OS. A company may want to know how many apps have gotten their database efforts automated, as an example, or perhaps how many apps are fully automated with middleware messaging systems. But the communications also must include keeping executives up to date on the ROI progress, and what areas of the company may be exhibiting resistance (for both legitimate and non-legitimate reasons). Expressing these outcomes can be sensitive and should be done with a modicum of care, so the folks assigned should have these skills to start with.
2. Information Preparation & Follow-Up: When a given application in the portfolio is targeted for onboarding to DevOps, a significant amount of information is usually gathered about it. While a company can create an automated system for development engineers to provide the data into an electronic web page or other means, very often questions arise about “how” to respond. You do not want to have your DevOps services engineers constantly deterred from their work to answer basic questions such as this, so having an adoption team able to provide the data quickly facilitates the overall goals. In addition, often the development engineers are too “busy” to provide the DevOps team the data they need. Again, someone needs to follow-up to ensure questions are actually answered. While it is easy to assume engineers will behave professionally and respond accordingly, that assumption in the real world results in long delays and interrupted workflows across multiple teams.
3. Training & Feature Expansions: Finally, the tools and architecture practices behind them need to be communicated effectively to the practitioners and participants of the DevOps services. When new programmers are hired, for example, they should have access to training materials on accessing to the DevOps toolsets and using base functionality, what governance procedures will impact them and more. On occasion, to facilitate adoption, an application executive sponsor and his or her immediate direct report engineering team leads will request a demonstration of a given DevOps tool or function. The adoption team should handle these requests and not divert a production DevOps engineer from his or her duties. And when a DevOps tool is updated or upgraded, the adoption team should develop the method to communicate the new ability, edit the existing documentation and ensure every practitioner is notified about the new features and how to use them.
Adoption Engagement Financials

Deciding how many people to dedicate to this function is a mix of your development environment complexity and what you have currently to complete your DevOps rollout efforts. If you want a 24×7 rollout, then you will need staffing levels to accommodate three shifts, seven days a week, with additional folks for vacations, holidays and sick leave. If you are only rolling out a 9-to-5, five-days-per-week effort, staffing numbers drop significantly. Resources, then, can be organized as one per line of business or one resource for every 50 applications in the portfolio (higher ratios are supportable). Whether you align the resources to the services you provide or to the customer audiences you support won’t matter nearly as much as having at least some resources dedicated to these efforts. As I stated earlier, a complete lack of resources dedicated to this function results in greatly extending the timelines for adoption of DevOps; worst case, in the failure of the transition entirely.

This kind of function is inherently considered overhead. Most DevOps leaders (generally emerging from an engineering background) naturally don’t consider this more administrative function as necessary. It doesn’t strictly add to the engineering capability or skills of the main onboarding teams, so they simply do not include it or divert budget to more “necessary” folks during planning. Organizations that don’t actually provide a guided DevOps service—that is, they simply install the tools and tell the developers to have at it—find their adoption efforts lagging quite a bit as well. The early adopters jump right on without coaxing, but the folks too busy with their own efforts to “try something new” never seem to get around to it. Finally, the guys who think, “Since it ain’t broke, don’t fix it,” will never adopt. Even in this kind of tooling-only services deployment, dedicated adoption resources would have resolved these issues in a far more timely manner. The overhead may be painful, but the alternative is far more painful. Once a company or division experiences a failed DevOps rollout, it rarely returns to try again, and the overall costs could be doubled or worse.

For organizations with the vision and perseverance to employ dedicated resources to facilitate adoption, the converse of the problems outlined above becomes the norm. Developer teams have the information they need to understand their own need and, more importantly, the benefits of adopting DevOps. The work relations between DevOps service provider and DevOps service consumer become highly efficient and mutually beneficial. The entire organization benefits from effective communications from the executive sponsors at the top to the engineering practitioners at the bottom. Execs know the costs, the progress, what is new and how it will help them reduce costs or speed up delivery. Practitioners know how to use the tooling, why it will help them and how to stay current on the changes that come along (and they invariably do). Practitioners appreciate being current on a given tool or skill set; this provides a way to do just that.

Impacts to the Bottom Line

Discreetly measuring the ROI for the application of adoption/engagement resources is a bit squishy. As a general estimation, take the timeline of the DevOps rollout you originally planned and multiply that by two to three. The cost of that delay in timeline (plus the risk of complete failure) is the cost delta to measure against hiring a few more folks (or allocating them from lesser-used areas already on staff). Usually the cost of failure far outweighs the benefits of expanding the overhead support teams as needed. In addition, the cost of a failed communication effort can grow over time. At the outset or launch of DevOps, the communications, whether in document or oral forms, will be fully up to date. But over time, as vendors add new features and new versions of the tooling emerge, practitioners won’t know how to take advantage of the new capabilities. Since many of these new features enhance speed or accuracy, the tendency to not use them—or use the inconsistently for lack of knowledge—will add up.

I find the resistance to the idea of adoption or engagement resources often is founded in the notion that engineers are plenty smart enough to figure this stuff out on their own and they will naturally gravitate to it, as ultimately it makes their lives easier and better. Yes, the engineers are smart enough and some will. However, engineers often build their own “ecosystems” of how an application should be built (which few others could understand or improve upon). They often are reluctant to tear this down in favor of corporately implemented templates (that everyone could understand and improve). They fear the loss of unique skills the company must depend upon. They fear the loss of being “special” and needed. Even though DevOps standardization makes builds and deployments consistent, reduces trouble tickets and improves quality and speed—which ultimately translates into fewer 2 a.m. phone calls for engineers to come fix—they are still reluctant to change (just like the rest of us). Having dedicated resources to help them through the value of this, and assure them of their continuing value in a differing area (the code we want them to write), can make a world of difference and ensure a transition does occur.

To continue the conversation, feel free to contact me.
July 29, 2016
Taking Stock of DevOps: Where to from Here?

Have you noticed how every technology trend goes through a series of stages on the path to mainstream adoption? First comes doubt and denial, then tacit acceptance and finally acknowledgement that it works fine after all. The DevOps movement is no different.

First came questions about what DevOps actually is and its usefulness in an enterprise context (whatever an enterprise actually means these days), then a trickle of success stories and finally the publication of tangible and quantifiable benefits.

Thankfully, we’ve moved on from the “Is it a bird or is it a plane?” stage. Of course, that doesn’t stop hype, but at least the publication of benefits—such as those recently illustrated in the global study, “Assembling the DevOps jigsaw“—allow us to cut through all the “DevOps solves global warming”-type of nonsense being written.

So with the value jury finally in, the next question we should be asking about DevOps is, Where to from here? Interestingly, the old Wikipedia entry for DevOps provides some guidance, stating that DevOps is:

… a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.

That’s pretty good, because it emphasizes the importance of collaboration across all IT functions (not just Dev and Ops). However, this still doesn’t quite cut it for me. Although lots of cultural and automation heavy lifting has been done to bridge Dev and Ops, more work is needed to understand how aligning other IT functions to DevOps actually benefits the function itself and the business. Also—and perhaps just as important—how aligning other business functions, such as HR and finance, can lead to more success.

DevOps Works Because It’s Good for Business

Business leaders talk in terms such as faster lead times, customer conversions and time-to-value, which (putting cultural discussion aside) is really the essence of DevOps. And because DevOps adoption directly correlates to making a buck, it has a fair chance of garnering attention and investment from the business.

That said then, information security and other professionals would do well to hitch their wagon to DevOps. One of the beauties of the movement is that teams collaborate and provide input much earlier in the development life cycle, with processes then automated to ensure faster release time and quality. By also involving security earlier, businesses could feasibly harden security, balancing all those “rain on your parade” audits and checklists with automated methods that ensure compliant configurations lead to faster deployments.

An interesting but important benefit is how this approach helps align IT security to business outcomes. Rather than proving its worth through a whole raft of technical sounding measures, such as penetration test scores, patched vulnerabilities or security incidents detected, security can report functional value in context of business goals, such as how automated compliance equals faster releases, leading to increased revenue.

Of course, DevOps doesn’t just involve Dev, Ops and security, it also will involve other functions providing valuable input to help increase speed and quality. Think of it like the old “Stone Soup” story but without the trickery—everyone, be they software designers, product managers and enterprise architects, providing advice and expertise earlier in the software life cycle so essential elements of resilience, supportability and scale are baked in right from the get-go.

DevOps Shouldn’t Start and End in IT

The DevOps way suggests that we shouldn’t just restrict ourselves to IT functions—start there, yes, but other facets of the business should also participate. This sounds like common sense, but in reality it’s more critical because the boundaries between business and digital have blurred significantly. Fail to recognize this and we could end up a silo of good intentions: culturally correct but lacking any teeth.

This explains why even the much-maligned HR function has a DevOps role to play. For too long, many HR departments have been fundamentally back-office, dipping their toes in the muddy waters of organizational culture with periodic staff surveys and performance appraisals. But this doesn’t go far enough. Now, HR leaders must step out onto software factory floor and work hand-in-step with other DevOps practitioners to identify all the organizational and psychological barriers that inhibit business growth and the development of talent.

Finance, too, must become aligned to DevOps. This involves moving beyond traditional IT cost-center thinking to developing new fluid funding models needed to stimulate software innovation by agile teams. This means business change agents must join forces with DevOps practitioners to look at better ways to capitalize or expense software development costs or optimally monetize new apps, APIs and information assets. Once again, the earlier this happens in the software life cycle, the better.

From an IT perspective, we’ve come a long way with DevOps in a relatively short amount of time. But this is only the start of the journey. Most businesses haven’t even considered transformation of the whole organization using DevOps principles as a change agent. Those that do most likely will gain first-mover advantage—and that’s a good place to be in an economy increasingly shaped by application software.

March 9, 2016
The Trouble With Enterprise DevOps

The literary world and beyond has been up in arms as of late regarding the use of the word ‘literally’. It seems that many are using the word literally when they mean figuratively. For example, if you say, “I literally split my pants laughing,” it would be plausible for one to look at your pants looking for a tear. Words are funny that way. When used to emphasize the action or outcome, some will take literary privilege. Enterprise is also one of those words that are used to convey emphasis often with disregard to the implied meaning.

When it comes to DevOps there has been a lot of debate about the modifier ‘enterprise’. Modifiers are supposed to add specificity to the noun it is modifying. Agreeably, enterprise is a horrible modifier for DevOps when used without additional modifiers representing scale. I have been, and continue to be, a big advocate of the concept of Enterprise DevOps. That said, I too have been remiss in my use of the word enterprise to further modify with the term ‘large-scale.’

I don’t remember exactly what triggered me to seek out if the word enterprise implied large, but when I did I was surprised to find that there is no implied meaning that enterprise means large and, in fact, can be modified with small-, medium- and large-scale to represent the appropriate size. As further evidence to the ambiguity of the use of the word enterprise, I worked for a company that divided their sales organization into enterprise and commercial accounts. Clearly, this organization believes that enterprise connotes large-scale since this group was responsible for selling to a specific class of customer that spent a significant amount of money with them. In this case, scale was identified by how much money the business spent with that vendor versus annual revenues versus number of employees. So, clearly, not only does the word enterprise not imply scale, but it also has different metrics that will determine the scale of an enterprise.

Merriam-Webster defines Enterprise as follows:

en·ter·prise

noun
\ˈen-tə(r)-ˌprīz\

: a project or activity that involves many people and that is often difficult

: a business organization

: the ability or desire to do dangerous or difficult things or to solve problems in new ways

Obviously, none of these meanings relate to size or scale, but two of the meanings do indicate difficulty. Let’s put that in the parking lot for later.

Why is this important? With regard to IT, I believe there is a tendency to throw around the word enterprise with no modifiers when we mean large-scale. For example, “Enterprise Software” is a term that is often used to describe very expensive and complex software applications that are designed to operate at the scale of the entire business versus the individual. Typically, the software described by enterprise software is found in mid- to large-scale enterprises where they can afford to acquire, configure and operate this type of software. Likewise, “Enterprise Storage” is a way to describe compute data storage environments for large organizations.

Likewise, “Enterprise DevOps” is a term that that is often used to represent adoption of DevOps practices in large, complex organizations with many different stakeholders and sub-organizations making it much more difficult to coordinate efforts around efforts like continuous delivery and continuous improvement.

Interestingly, and I believe accidentally, implementing enterprise software and adopting enterprise DevOps are difficult projects. So, based on our Webster’s definition, enterprise works as a modifier for these nouns. But there’s still the issue that for small-, mid- and large-scale enterprises the challenges and hurdles associated with DevOps adoption vary enough that the constraints and bottlenecks require different approaches to remove. This is especially true of large-scale global enterprises where development exists in four continents, operations data centers exist in multiple countries on four continents and the business operates in six continents with a comprised IT staff of 120,000 people.

I for one will be very careful in the future to define what I mean when I’m using the word enterprise in the future. If I’m talking about large-scale enterprises, which I usually am, I will make sure that early on in my writings and presentations I specify that when you see enterprise going forward I’m talking about large-scale enterprises.

January 23, 2015
The Conundrum of Adopting DevOps within Organizational Constraints

I wish I had a dollar for each time I’ve now heard, “we’re adopting DevOps, but we have to operate within the constraints of what the business is ready to accept.” Basically, this is becoming the battle cry of many enterprise IT professionals that are DevOps believers, but are stuck with the limitations of operating within a complex, political and immovable business structure.

One on hand, it is very pragmatic to approach adoption of new methods, techniques, technologies, etc. on a small scale and then expand based upon success. However, what is the result of a DevOps initiative in which existing organizational constraints and bottlenecks continue to remain in place?

If you’ve been in the business world for more than a few years you’ve probably already had the experience of having a really good idea only to come to the realization that implementation of that idea requires cooperation of another organization. For example, Marketing might have a great concept for how to acquire new customers, but would require sales management to provide incentives to the sales team for it to succeed. For purposes of this example, let’s assume that marketing has made its case to sales and sales rejects the proposal (many times there is a perception that the idea will be rejected limiting those from even trying; this is a worst-case scenario for any business). In this case, Marketing might attempt to operate around the need for the sales incentive and, ultimately, come to the realization to abort the plan or lower expectations for results.

Is anything more debilitating to morale then end up with these two outcomes as the only choices? What would you do if you were in the position of driving this for Marketing?

Often times in businesses there is no grievance committee. To steal a line from “A League Of Their Own”, “there’s no crying in business!” What DevOps is surfacing is that business is about relationships and managing cross-departmental and extra-departmental relationships is not something that many IT professionals have had to or want to foster. Ultimately, this will have a detrimental impact on DevOps adoption.

In most cases, DevOps requires that some leader within IT steps up with the idea to foster a frictionless ideation-to-operation lifecycle. By frictionless I mean the removal of as many bottlenecks and constraints for transitioning from the idea phase to a production-ready support application. Like Marketing in my earlier example, this may require this leader to “sell” their idea to the heads of IT Operations, Application Development, Quality Assurance, Information Security, and potentially C-level executives. A “No” response by any of these teams will result in the leader working around this limitation resulting in no change for the processes and work output of that particular group or attempting to do what they can within the organizational boundaries within their control.

Hence, business agility is tied to velocity of accepting change, which is further dependent upon individuals fostering a strong enough personal relationship–at a minimum one of mutual respect–to be willing to accept risk in support of a larger goal. I believe many would see this as a high-risk constraint on the business agility deliverable.

One way to increase likelihood of avoiding this trap? DevOps needs to be sponsored from C-level management from the start inclusive of the necessary incentives required to help drive the changes that will lead to more rapid adoption of DevOps practices and speed the way to business agility. There’s enough evidence now available to convince most C-level executives that a DevOps program is a worthy investment in moving their IT organization toward greater alignment with their business goals, producing faster, reducing operating overhead and improving quality.

As with most changes within IT, and DevOps adoption is no different, there is a requirement for bottom up support as those closest to the work need to believe, and there is a top-down requirement that provides the coverage, financing. motivation and accountability to the business to allow the change to occur.

November 20, 2014
DevOps the movement, or the function?

All the ISVs and Enterprises are having the same question, who/what is DevOps. We get in a virtual room and talk about it, but we are often all scratching our heads at the same time. We are not confused from a technology or definition standpoint. There is so much chatter about this thing, it’s just hard to find the person or group that is doing it.

My response to when I’m asked about DevOps is always the same. Are you are talking about DevOps the movement, or the function? The movement is what we are all hot and bothered about, but the function is where it really comes together and problems are solved. And even if you hate the movement, I guarantee your dev and operations team are inching in that direction, and some portion of the work already being done is in the DevOps spirit. (more…)

August 12, 2014