devopsy.kinsta.cloud

Tag: devops

Carving through the hype – take the DevOps maturity assessment

As anyone who spends time with their family over the holidays can attest, the notion of maturity is a highly subjective concept.

Whether it’s sizing up the next generation’s advancement or defaulting to time-honored inter-sibling behaviors, annual get-togethers offer tangible proof of what’s new and those things that likely won’t ever change.

In the domain of DevOps – an umbrella concept that encompasses a massive array of processes and supporting capabilities – gauging the maturity of your organization’s standing is also a highly interpretive task.

Given that “DevOps” means something different to nearly every organization, based on its unique makeup, methodologies, tools, and most importantly, business goals, attempting to measure progress against any outside model may seem an effort of limited value.

That said, as an increasing number of organizations seek to embrace DevOps, and growing recognition that well-worn stories of leading-edge “unicorns” don’t relate closely to most people’s real-world expectations, many teams are left wondering where their own efforts stand, especially in comparison to their peers.

To help acquit this pursuit, and allow organizations to scope their progress, CA recently launched the second iteration of its online DevOps Assessment.

Split into three short surveys covering core limbs of the DevOps tree – “Develop and Test”, “Release and Deploy”, and “Manage and Monitor” – this free tool offers detailed insight into how your organization’s maturity stacks up to that of other practitioners.

For instance, in the domain of development, how well do your teams fare in defining and managing requirements, and then presenting them to others in a structured manner? Related to release cycles, are your teams truly meeting business-driven expectations for more frequent application deployments, shorter lead times, and higher success rates? Or, when it comes to applications monitoring, are you able to distinguish the most critical and recurrent problems and how they truly impact business services?

These are perhaps some of the most fundamental questions that one could apply to measurement of DevOps adoption in general, but further investigation attempts to take a closer look at more finite, underlying issues.

Are your development teams accurately replicating realistic conditions from production systems to create virtual services and testing scenarios? Are your application release deployments fully automated across development, test and production environments? Can your teams monitor complete business services that link user experience, transactions and applications to infrastructure to pinpoint any root cause issues?

The best thing about the survey is that it immediately provides visibility into how your answers compare to those of previous respondents. There’s no fuzzy math or editorial interpretation (though we may highlight trends in a report at some point), merely instant validation, and the option to create a customized report card charting where your efforts stand in relation to those of your peers.

If you’re wondering precisely just how to achieve your long-term DevOps goals comparative to where you stand today, it might even be worth leveraging some of the involved questions for the purpose of evolving process and methodology.

The only remaining questions are: Do you think that you’re ahead of the curve? Are you afraid to find out just how far you’re behind the crowd? And most importantly, what do you have to lose?

Take the survey today and get a real-world fix on your overall level of DevOps maturity. Guaranteed it’s a far more informative activity than debating family and friends over whose turn it is to carve the turkey, or wash the dishes.

December 3, 2015
Can We Stop Talking About DevOps?

I first heard the term DevOps from a friend in the software business when I was working at Dell HQ in Round Rock, TX. He recommended that I read The Phoenix Project, by Gene Kim, Kevin Behr and George Spafford. I did read it and I found it a fascinating story, but as a long-time network administrator (to oversimplify as much as possible) and having never been involved in developing software, I wasn’t quite sure how it applied to me. It was enough to pique my interest though and drove me to volunteer at a DevOpsDays event in Austin. Within weeks I left Dell and joined a small software company, where I could have a better chance of getting my arms around this slippery pig called DevOps and more hands-on practice with the related tools and techniques.

So imagine my surprise when a year later, the same old friend who introduced me to DevOps suggested that the end-goal of a DevOps transformation should be that we stop talking about DevOps. Uh-oh, I thought, he’s lost the plot. But he made his case by pointing out that adding testers to dev teams–a typical step in any Agile transformation–doesn’t result in new devtest or agiledev teams, they remain simply “dev teams”. Once a business/group has fully internalized the Agile or DevOps values and behaviors, he argued, ‘working in an Agile or DevOps way’ becomes simply ‘working’. This is why many DevOps promoters, myself included, have a negative reaction to seeing ‘DevOps’ in job titles, job descriptions, or department names. While it simplifies the job of identifying which job candidates have a DevOps mindset or skillset, it effectively excuses everyone else in the organization from taking responsibility for change. “Doing DevOps” becomes the job of a particular individual, team or department instead of a philosophy internalized by the organization.

Of course the horse is already out of the barn on that one. Each year we see an increase in the number of businesses advertising for DevOps Engineers, forming DevOps departments or listing DevOps among the required skills for a position. It doesn’t matter whether we think this is a good thing or bad thing, evolution will take its course and there’s little we can do to stop it. What we can do is observe, acknowledge and adapt. Sure, the dangers are real. A DevOps department can easily become just a third silo or the DevOps Engineer might become the scapegoat for everything that goes wrong between development and operations. But if a DevOps Engineer, VP of DevOps or DevOps department can form, contribute to and/or nurture an environment of increased empathy, faster feedback and continual growth, that’s awesome; put the focus there. Don’t spin your wheels arguing that they just “don’t get it” or “they’re doing it wrong”.

I’ve spent the past couple years researching, promoting and attempting to practice this thing we call DevOps. While it’s widely believed that DevOps is impossible to define, I am firmly in the camp of those who believe that empathy is, to quote Jeff Sussna, “the essence of DevOps”. Just as the sales team needs to have empathy for its customers, everyone in the value chain needs to have empathy for each other. I’m aware that many people find this term too “touchy-feely”, but the business benefit of more harmonious interaction between one’s teams and between the organization and its customers is clear. The faster and more effective one is at converting solutions into real value for customers, the more successful one will be in the market. Thus being empathetic isn’t just being a good citizen, it’s being a good businessperson.

Taking it a step further, someone on Twitter recently suggested that “DevOps has nothing to do with technology”. The statement seemed ridiculous on its face. After all, the term ‘DevOps’– literally a portmanteau formed from the words ‘developers’ and ‘operations’–was coined by Patrick Dubois, a technologist intent on improving the process of building and deploying software. But as I thought about it I started to understand. As the DevOps movement has evolved, the most fundamental components its promoters have identified, from Gene Kim’s “Three Ways” (Systems Thinking, Amplify Feedback Loops, Culture of Continual Experimentation and Learning), to John Willis and Damon Edwards’ CAMS (Culture, Automation, Measurement, Sharing), to Dave Zweiback’s ICE (Inclusivity, Complex Systems, Empathy), are primarily about how people work. It doesn’t matter if one is building software or running a school, DevOps principles are sound.

I recently tweeted the observation that “anyone who attempts to define DevOps in a paragraph is trying to sell you something”, adding “not necessarily a bad thing, just buyer beware”. This wasn’t a criticism of tool providers; many tools, from build automation to log monitoring, are essential to an effective DevOps transformation. It was a reminder that the problems and solutions DevOps is concerned with are complex and nuanced. There is no prescribed toolset or checklist of actions one can take to be successful; an effective DevOps transformation requires thoughtful, committed action across the whole range of people, practices and products one uses in their work. It might take months or years of practice, but maybe one day we can all stop talking about DevOps.

November 5, 2015
Combining SecOps and DevOps

Security has to be top of mind for most any company that is moving, or has moved, to the cloud. And, businesses know they need to act swiftly to ensure that any new products or services they’re dreaming up do not expose them to risk.

How can they do that when the fast-moving nature of the cloud is leaving proper security practices in the dust? The problem today is that today’s security solutions are proprietary, too slow and take too many resources.

Bottom line, the security model that has served most businesses well was never built for speed, and is simply unsustainable for opportunities in today’s cloud-centric world. Today, security solutions must be agile, lightweight, loosely coupled and extensible.

On the front lines at various companies you’ll see a new type of cooperation – where two teams most directly involved in a potential solution, development and security – are breaking down the traditional (and often opposing) silos and collaborating more openly to drive secure innovation from the start.

We’re seeing a new “marriage” of SecOps and DevOps that creates a whole new mentality for driving innovation inside and outside of organizations. This new mentality allows security and DevOps to find common ground to make it easier for organizations to align their security goals with the delivery of their products at today’s rapid speed of business.

While businesses are changing internal structures to address cloud security, there are also a number of new solutions that can be deployed against a company’s clouds and deliver security intelligence back to the DevOps teams.

These kinds of tools are especially important for start-ups and SMBs that face unique challenges securing their businesses from cyber attacks and preventing data breaches.

By encouraging greater collaboration between security and DevOps, and relying on outside solutions to assess and identify potential threats as new products and services are developed, businesses of all sizes can feel a higher level of confidence that they’re addressing security concerns by enforcing industry-leading security practices every step of the way.

About the Author:/Tim Prendergast

Tim Prendergast co-founded Evident.io to help others avoid the pain he endured when helping Adobe adopt the cloud at a massive level. After years of building, operating, and securing services in AWS, he set out to make security approachable and repeatable for companies of all sizes. Tim led technology teams at Adobe, Ingenuity, Ticketmaster, and McAfee.

November 3, 2015
5 Tips for Building a Winning DevOps Culture
Despite our cognitive prowess, humans are just like other animal in the food chain. We follow patterns of behavior based on survival. If food is safe to eat today, we’ll eat it tomorrow. If we can navigate a road without getting hurt, we’ll do it again and again.

This explains why change is so hard. Evolutionary magic has taught us to avoid stuff that could harm or kill us – in life and even in business.

But the business jungle is changing faster and far more radically than ever before. The pace and ubiquity of technology has resulted in once sturdy business models being brutally felled. Now we must move out of our comfort zones – or get eaten alive.

Businesses now require regular and sustained innovation, but this is problematic for many organizations more used to operating in safe mode. For them, fear of change reigns supreme – even when the company is losing market share and talent is leaving in droves.

The situation is recoverable when leadership commits to building culture of innovation. This is especially important in IT, because it’s here where innovation now starts and ends. To this end, organizations are rushing to embrace Agile and DevOps – the practices of choice for rapidly delivering high quality software.

But when it comes to culture nothing is easy. Here are five tips to help ensure success:
1. Avoid Building Elitist DevOps Teams – the natural tendency with any new initiative is to build out a separate team. This means bringing in outside experts, cherry picking what’s seen as the best internal talent across development and operations, and then operating distinctly from the rest of IT.
It must be remembered that DevOps isn’t a function, but a model in which development and operations collaborate. Therefore building a separate team is just creating another silo, which because of the “elitist” association could create even more friction.

DevOps teams can valuable during early stages of a program, but only then as a transitional practice. In these case members of the team are chartered to spread knowledge; building the bridges across the organization and then disbanding once practices start to take hold.
1. Cull Elitists and Destructive Narcissists – a strong DevOps culture is based on collaboration and empathy; sharing success and learning from failures. If, however, initiatives are led by individuals who strive for personal glory and kudos at the expense of everything – especially staff morale and wellbeing, then there’s a problem.
Doubly difficult is the fact that people in this category are energetic extroverts; appearing ideally suited to spearheading important cultural change initiatives. But remember this – energy doesn’t always equal intelligence, so seek out the big thinkers over the big talkers. They’re just as likely to be introverts, only netter equipped with the intellectual persistence and the emotional smarts needed to help build a thriving culture.
1. Reward Wishful Thinking and Craziness – ever wondered where great business ideas from the likes of AirBnB came from? Probably from folks challenging the status quo by creating problems customers didn’t know they had (and then solving them with software)– like – what if we could take that wasteful spare room you have and turn it into a cash generating mini-hotel?
In a DevOps context, we can use a similar approach. Looking at the ways processes are being conducted and then suggesting counterintuitive alternatives. For example, what if our change management process is completely wrong – can we find ways improve automation for agile development? Why should we wait for production monitoring – what if we build it during coding and testing to increase resilience?

In a strong DevOps culture suggesting ideas is openly encouraged and rewarded. Without it, great ideas get lost or unnoticed, or worse, get belittled and smashed by those elitists and narcissists.
1. Have a Healthier Respect for Failure – if you want to kill DevOps before starting, go ahead and talk up past failures – like – “We tried agile five year ago and it was a train wreck –DevOps will be no different!” Glass half-empty thinking like this is detrimental because it put the brakes on talking risks and exploring a profitable digital future.
Nobody likes talking about failure, but the key to making progress with DevOps is to accept that mistakes happen all the time. What’s key is treating every fail or screw-up as a learning point. That way we stop talking about things that didn’t work before, and start describing them as lessons which help build a brighter future.

Taking the fear out of failure needs a lot of executive support. Management should begin a parallel process of rewarding sensible risk taking and removing any structures and incentives that stifle innovative thinking.
1. Walk the People and Process Pipeline – even with great tools, DevOps won’t deliver anything if sub-optimal processes or organizational friction persist. In most cases defects and delays can be put down to people enforcing rigid policies or relying on manual and error prone handoffs.
One good practice taken from the world of manufacturing is taking a “value walk” across your own software factory. This involves spending time interacting with people as they conduct their jobs (develop, test, release etc.) – not to point fault, but to understand any situational stresses that increase waste and technical debt, and could be remedied from automation.

Carving out opportunities from the digital chaos and disruption is the perfect place for DevOps. But don’t get carried away – change is hard. Make sure you have the right leadership, practitioners and counterintuitive thinking needed to start your transformation journey– and keeps everyone onboard.
November 2, 2015
Survey says network agility is still immature

At least that’s the word from SDx Central’s Cloud Management, Orchestration and DevOps 2015 Report in which 76% of respondents said the network was the most immature component in the cloud management stack.

Now to be fair, the network is one of the last components (I’m looking at you, security) to get on board the “automate or die” train, which has already left the station. That’s partly due to pressures from increased DevOps adoption in general and more specifically thanks to greater enterprise penetration which is continuing to up the amperage in the data center with respect to velocity and ease of deployment of all the network bits, bytes, and pipes needed to support each and every application.

It’s also partly due to the complexity of the network environment and the blast radius of potential errors or misconfigurations as well as the broad set of differences in the object models (and therefore APIs) used to configure, manage, and automate provisioning of network services. The more features and capabilities, the more differences between them.

OpenStack manages this difference by forcing standardization; that is, it defines the interface for LBaaS and if you want to be a part of the stack, you have to conform. Cisco ACI manages the difference by taking a declarative policy-based approach that let’s plug-ins define their own interfaces and expose them to ACI in a standardized way. VMware NSX and related technologies take yet another approach, leveraging its ecosystems’ APIs to integrate and orchestrate the network.

All are relatively new to the game (OpenStack may be the exception but even its network implementation has lagged far behind other components of its system) and thus the perception that the network is the most immature in the cloud management stack would seem to be reflective of reality.

But at least it’s heading in the right direction.

The network was going to have to be included at some point in this grand journey to transform the data center through automation and orchestration. At some point Agile and DevOps methodologies being embraced by dev and ops were going to start paying off in the form of more applications with more frequent deploys. Eventually that was going to overwhelm the network (and its staff) and give them cause to start figuring out how they were going to transform the network from the static and very fixed methods of scale and management to a more modern dynamic and fluid method.

Eventually is now. Whether it’s DevOps expanding into the network or SDN or cloud management stacks, the network has to mature in terms of its orchestration and automation capabilities if organizations are going to continue on their journey toward the agile network.

We’re still trying to move out of the first phase in that transformation; toward a culture inclusive of measuring and standardization with templates (or configurable policies, if you prefer). We’ve got a long way to go toward a sustainable, agile network and just as it’s taken years for Agile to truly envelope most projects within the enterprise, it’s going to take years for the network to get from where we are today to where we suddenly want to be yesterday but accept that we won’t get there till tomorrow.

October 21, 2015
A Most Perplexing Problem

A most perplexing problem

— ROELBOB

October 20, 2015
How Fast Is Fast Enough?
One of the primary goal of DevOps is the ability of an organization to bring an idea to market faster. But how fast is fast enough? Do they need to improve time to market by 10%, 20%, 50%..90%? Do all applications need to ultimately be released within hours? In order to compete do we all have to be the Etsy or the Netflix’s of the world?

Unfortunately there is no simple answer. Optimal application delivery speed (aka time to market) varies drastically across industries, markets, organizations, and even within an organization’s own application portfolio. Remember “two speed IT”.

In other words there is no “one fit for all” when it comes to speed. Yet defining your optimal speed – goal – is critical to your DevOps success. Without it, its almost impossible to provide a vision, measure progress, and fundamentally change the way you delivery software. For example, IT is very good at measuring costs. In fact they measure costs from every way to Sunday. As a result, cost takeout becomes the fundamental value metric for service delivery – “how low can you go to delivery the same service”. Similarly, if speed and agility is the goal then we must start with measuring our current velocity and then setting (realistic) goals for the future state.

The Definition of Speed

Before we go about trying to determine an applications optimal speed it is important that we first agree on the definition of speed. We like to think that speed is a fairly simple concept, but its amazing how mis understood it is.

Many organizations new to DevOps simply equate speed to release cycles. They believe that if they increase the number of cycles then they are improving their time to market. Unfortunately it does not work that way. Improvement in release frequency is a natural outcome of going faster (as we will see in the example below) but not the driver of speed.

True cycle time is measured from end to end – when the idea enters the development funnel to the time it is released to the end user. In other words it’s the Work In Progress (WIP) time for that particular piece of code and any improvement in speed is the reduction of this WIP time.

For example, a healthcare client recently shared with us that it takes them just 20 days to develop a medium size enhancement. For them, their cycle time was 20 days per enhancement. But on further inspection we found that it takes 20 days to determine requirements, 10 days for setting up environments (while using cloud), another 15 days for testing, 10 days for moving code from one environment to another, and a whopping 15 days for approvals. When we added all that up, we discovered that their true time to market (speed) for that enhancement was just over 90 days.

Once we were able to define speed in tsurehis context, it opened up an entire new world of dialogue within the organization. Now instead of optimizing 20 days, they have another 70 days of activities to pick on. Even if they were to shave just a mere 1/3 of the 70 days (cue automation with some simple processes engineering) they would be able to improve their time to market to 65 days. And as an added bonus, the team instead of just delivering 4 enhancements per year (90 days x 4) they can now deliver 5 enhancements (65 days x 5) much faster.

By defining speed in such broad terms, it not only gives IT teams a glimpse at the big picture but also visibility into areas of wastes, opportunities for true end to end improvement, and a platform for collaboration.

Now that we have our definition right, lets get on to answering the million dollar question,

How fast should I be (what is my optimal speed)?

The simple answer is fast enough to delight the customer and beat the competition. But to determine at what point you are able to achieve this goal is a bit more complicated.

Most organizations try to answer this question by looking inward. They perform a detailed value stream mapping exercise, determine cycle time for each activity, identify bottlenecks, and then triangulate how fast they can go if they eliminate some of the key bottleneck.

Unfortunately, speed is not a function of how fast can you go (IT view) but a function of potential benefits (business / market view). More precisely, your optimal speed is directly depended on the additional benefits the business will enjoy (additional revenue, higher customer acquisition, better customer retention etc.) as a result of greater velocity.

To help understand this relationship between benefit and speed better, ask yourself the following three questions,
1. If we were to reduce our cycle time (from idea to production) by 10%, 20%, 30%, 40% etc., what is the incremental benefit to the business
2. Can we quantify this benefit?
3. How sensitive is this benefit to speed? Are they inversely proportionate, is there a benefit / speed plateau?
By doing so, there is a good chance that most applications will fall within one of the three scenarios.
1. Benefit and Speed Are Directly Proportional
For some businesses, speed is king. The faster you can deliver a product the greater the incremental benefit. Consumer facing apps (Facebook, Linked In etc.) focused on revenue generation / customer acquisition work well in this scenario. For these applications, there is essentially no speed limit. The rule of thumb is step on the gas and get out of my way.

Optimal Speed: No speed limit, step on the gas
1. Benefit Improves But Only To A Certain Point
Most SaaS applications (SFDC, Workday etc.) fall within this category. At a certain point the incremental benefit diminishes as speed increases. In other words, users like the regular updates and upgrades but to a certain point. Change too much too fast and you end up delivering little additional value. In this case, there is an optimal speed and any investment in speed after that is a waste of money.

Optimal Speed: Limit your speed to the point where benefits plateau
1. Benefit and Speed Are Adversely / Not Related
This is the opposite of A, where speed has an adverse / no impact on benefit. Here users prize stability and status quo over anything else. Changes are welcomed but need to be few and far between. Many on-prem legacy applications fall into this category. Imagine if your ERP provider published a new update (mini upgrade) every day. It would wreak havoc to the organization. If this happened to your general ledger system, you would never be able to close your books. If you find yourself in this category it is best to go pick a different application.

Optimal Speed: None, stability is prized over changes

Two Caveats

The graphs are a great representation of the various options but there are two caveats that every organization should be aware of, cost and competition.

Cost: The speed limit makes little sense if the cost of getting to that speed is greater than the incremental benefit potential. After all, like any other IT project ROI is key in deciding if DevOps is worth investing in.

Competition: Ultimately…competition holds the trump card. No matter what your charts say and / or your cost model shows, if the competition is going faster…you have no choice but to match that speed or better yet, beat that speed. Which is why we urge many of our clients to invest into DevOps early, set the benchmark, and build a competitive advantage.

Happy speeding!!

About the Author/Mustafa Kapadia

Mustafa Kapadia is Service Line Leader for IBM’s DevOps practice, a business advisory practice focused on helping large enterprises transform their software & application delivery. Through DevOps, organizations can get software to market faster, with better quality, less defects, reduced risk and shortened lead times.

Prior to joining IBM, Mustafa was a management consultant with Deloitte’s Strategy & Operations practice. He lives in San Francisco Bay Area, is an avid blogger (when time permitting), a speaker, and and advisor to start ups.

You can follow Mustafa on LinkedIn: https://www.linkedin.com/in/kapadiamustafa and Twitter: https://twitter.com/mkapadiatweets
October 14, 2015
Digital Disrupters – Building a DevOps Leadership Profile
While the advancement of DevOps methodology remains fairly nascent for many organizations, an ever-expanding class of leading practitioners are evolving a wide range of related best practices.

Beyond the well-worn concept of “unicorns” – the scant few organizations that stand as mythical examples of DevOps nirvana – this broader set of early adopters have begun to pull back the curtain on their efforts, lending further detail to the strategies that have bred this current model for success.

Last week, industry analysts Freeform Dynamics published valuable research that highlights the ongoing work of such DevOps innovators, dubbed as “Digital Disrupters” for their accomplishments in pursuing larger digital transformation. The report “Exploiting the Software Advantage” – sponsored by CA Technologies, outlines a critical set of initiatives crucial to navigating the DevOps landscape.

What are the specific hallmarks of those organizations leading the charge? Where are others struggling to catch-up? Many of the Freeform Dynamics survey results, based on 1442 respondents, reaffirm widespread DevOps observations, while other findings serve to shed new light, including:
- Everyone builds software: Perception is, in fact, reality and to deeply engrain digital transformation, Digital Disruptors are increasingly identifying with this mantra. While 95% of leaders have committed to becoming more app-centric, only 51% of mainstream organizations have adopted this persona. Similarly, 84% of Disruptors directly identify as “software companies”, regardless of industry, compared to 40% among the masses.
- Transformation is required: This point may seem obvious, but it certainly bears repeating. A whopping 92% of leaders have actively moved to break down traditional silos between Dev and Ops, with 51% of those organizations having already completed this work. By comparison, only 18% of mainstream organizations claim to have done the same, supported by 59% who at least share this more collaborative DevOps vision.
- Commitment is critical: This may also seem like a no-brainer, but the numbers bear out this requirement. Some 77% of Disruptors have agile development methodologies in place, with 70% having “broadly” implemented DevOps activities. For mainstream organizations, these metrics rate at only 31% and 21%, respectively; leaders are going all-in and appreciating the benefits, and those that follow will need to do the same.
- Experimentation is omnipresent: To garner the benefits of continuous delivery, embracing trial and error is a must. Among Disruptors, 93% recognized the need to “experiment and fail quickly on the road to success”, compared to only 58% of mainstream organizations. Some 95% of leaders have already shifted from fixed product cycles to continuous innovation, while only 56% of the mainstream have made this leap.
- APIs are everywhere: Ubiquitous integration, both in-house and in connecting to third parties, has only increased emphasis on the API. Disruptors are resoundingly focused on API management, with 68% using APIs to integrate third party services into their applications, and 66% to offer external access to systems and data. Mainstream peers compare at only 26% and 24%, respectively, denoting a sizable API management gap.
These are only a handful of the most dramatic and obvious areas where DevOps advocates have clearly re-architected their approach, separating themselves from those organizations that have yet to go all-in; it doesn’t stop there.

As highlighted in the research, other areas of differentiation and dichotomy include cross-functional alignment, emphasis on digital channels, use of digital to drive core business efficiency, and even funding of digital investments.

Beyond these key philosophical milestones that litter the pathway to DevOps success, the survey also highlights the vast array of strategic goals that these organizations have sought to accomplish. The results spotlight the massive range of significant business benefits that practitioners believe DevOps can deliver.

Leading use cases include:
- Improved customer satisfaction (49%)
- Better workforce productivity (44%)
- Improved customer experience (41%)
- Improved competitive differentiation (38%)
- Better agility / speed-to-market (37%)
- Opening up of new markets (35%)
- Creation of new business models (30%)
- Creation of new routes to market (26%)
If one were to take those outcomes out of context, unrelated to the impact of DevOps, it’s fair to say that they read like a generic list of leading business initiatives – further underlining the movement’s overall relevance.

That’s not to say this is all accomplished easily. Report respondents detail hard won victories that required significant time and investment to achieve all this DevOps-driven advancement. After all, the notion of “disruption” doesn’t exactly evoke images of ease or comfort.

Click here to read the report for yourself – there’s a lot more to be considered. Namely, how well your organization measures up in affecting digital transformation in its own right, and where it can take steps to move forward.
October 14, 2015
DevOps- Is [Ops] operations contribution equally Important?
I started my technology writing journey with a 2 part blog (One & Two) on Service Delivery Excellence, before jumping into the DEVOPS bandwagon, but now as I read across all related discussions, I end up feeling that the good kid is always the DEV and OPS are the unnecessary tag along.

We always talk about how the end goal is to make quicker releases, fixated towards adding value with continuous deployments, insinuating that OPS is the roadblock towards that goal, or that collaboration is the name of the game, and OPS should stop being confrontational, etc, etc.

Today, I am on the other side of the fence and will sit on judgment on the question of if any changes are needed at all for the OPS teams to engage themselves into the DEVOPS culture.

The lifecycle framework, defined by ITIL, COBIT or MOF (looking at the ‘Microsoft Operations Framework’ with renewed interest after my initial days of GRC stint) is quite similar across all phases of IT Service Delivery and consistent with the DEVOPS principles of stable, scalable, lean and quicker delivery of value to the user community.

ITSM’s broadly references
- Focus on services rather than systems
- Process oriented management approach
- Continual Improvement as part of their Deliver, Support and Operate lifecycle,
Then, the questions arise:
- Does the Service Delivery Framework (SDF) changes?
- Do we have to revisit the 3P’s (policies, processes & procedures) which are working well, as we move on to align ourselves with DEVOPS?
Historically in almost all large organizations, Operations [OPS] has always worked in silo, minimal trust of the development & testing teams to deliver a high quality change with a very suspicious view of all changes, as understandably they are responsible for the stability and maximizing availability of the Production environment with a consistent user experience.

On the other hand Developers [DEV] are under greater stress to deliver features and fix defects at a much faster pace due to many reasons. Shorter coding windows, cutting corners on testing cycles, deferring performance/ regression issues ( yes it happens!), and of course your team’s efforts are not just measured but the survival depends on the count of production runs rather than on quality, innovation or improvements.

“Throwing a dead cat over the wall” is how someone wrote of the handover of new code to OPS, I wouldn’t agree with that analogy, as OPS will at least expect it to land on three legs, a DOA would be thrown back with the same impunity!

The business value, Operations add in terms of availability and support to the customer far exceeds the risk of adding half-baked features in the ‘need for speed’. On the other hand it’s also imperative that we work towards a goal of a collaborative approach to a stable, sustainable and faster delivery of features to remain competitive.

I define DEVOPS as “combining a right mix of interdependent variables like People, Process and tools for fast and quality software delivery”, and Operations contribution towards this effort spans across all the variables adding immense value towards a successful initiative, with new insight of the challenges and shared concerns in improving the processes and delivering better software.

DEVOPS is not just about creating scalable infrastructure on the fly, or implement newer tools for rapid and automated deployments, or even about creating a SWAT response around monitoring. It is equally about envisaging a collaborative model, ensconced in proven principles and practices in order to add business value by delivering quality software rapidly.

So, what should OPS do differently to be an effective contributor of the DEVOPS team?

To start with, OPS should grab the advantage of being involved at the outset of the planned lifecycle by contributing with constructive inputs and using their expertise in:
- Assessing Infrastructure impact and capacity review.
- Influence design decisions & operational needs.
- Review all Service commitments and SLA’s
- Security and entitlement management
- Highlight any potential changes to operational procedures.
- Update monitoring and alert mechanisms
- Improve automation.
- Upgrade run-books; training of the service desk, share knowledge.
OPS also can keep a strict overview in the issues faced during the deployment/testing journey of the release and measure it against their own operational readiness thresholds.

The best outcome of this collaboration, in my opinion is that there will be no need for a ‘Warranty’ or ‘Initial support’ period by the DEV teams. OPS will be fully aware of the journey and has partnered to ensure the ‘Cat’ has passed the minimum health checkup and also is fully aligned with the changes to the support model from day one.

In fact the ‘Cat’ will no more be chucked over the wall, rather will formally pass through immigration!

Thank you for the time.

Visit my blog http://askhurram.com/

Read On, Live On.
October 7, 2015
DevOps Leadership Series 2015: Women & Diversity – a diversity of thought and contribution

Many of the leading minds and practitioners in the DevOps movement are women. I hope that comes as no surprise to you. DevOps has always embraced a diversity of thought and contribution. Case in point, close to 50% of the presenters at this year’s DevOps Days Boston event were women.

In this episode of the DevOps Leadership Series, we caught up with Jennifer Davis, co-author of Effective DevOps (O’Reilly 2015, $31) and software engineer at Chef. Jennifer discusses a greater diversification of what DevOps means. She sees more explicit efforts to expand DevOps into QA, security, DBAs, and other functional teams across the organization. Jennifer also discuss the benefit of re-setting one’s expectations on the meaning of certain words (e.g., agile, test driven development, audit driven development) to accelerate progress and remove roadblocks:

https://www.youtube.com/watch?v=B-zONUI5KQ4

We then sat down with James Meickle, Site Reliability Engineer at Harvard and member of the organizing committee for DevOps Days Boston. James witnessed distinct growth over last year in the diversity of companies in attendance — both from a size and industry perspective. James also discusses the importance of diversity that the organizing committee insisted upon as they planned for the event. If you are organizing your own DevOps Days event, be sure to have a listen:

https://www.youtube.com/watch?v=BZZCjw9YEps

If you missed part one of our series from DevOps Days Boston, be sure to watch these interviews from Beno Chapman of Constant Contact, Anthony Spring of Yieldbot, and Jeremiah Sullivan of Puppet Labs.

Want learn more from the leading minds in DevOps? You can find the entire library of 21 videos from this series on YouTube.

Special thanks to my colleague, Mark Miller for capturing these videos for us at the event.

October 1, 2015