The latest expert opinions, articles, and guides for the Java professional.

Release Management for Enterprises

Different teams, different motivations

It’s no surprise that Development teams and Operations teams think about things differently, but have you ever considered that what makes both teams work best are actually diametrically opposed?

Business stakeholders care most about leveraging technology to further business goals and stay competitive. Which means, software and systems must constantly evolve to meet user, market or enterprise needs and perform flawlessly, all the time.

We’re sure you see the dichotomy in the statement, after all change != stability. This need for change in Development and stability in Operations drives a wedge between teams responsible to developing and delivering software.

Developers <3 Change Operations <3 Stability

The dev guys are always looking to add cool new features, improve others and make the software more relevant to current needs. They have more than a decade of practice with Agile, collaboration and continuous integration tools. All of these help devs produce new releases at a blazingly fast rate.

The Ops guys are the Night’s Watch a.k.a. the guardians who make sure everything runs like clockwork. They keep systems oiled and optimized to run reliably during slow and peak usage. The business and customer relies on software stability and lean on the Ops team to deliver it 24 hours a day, 7 days a week.

Changes causes things to break. So when dev teams pushes for change, the ops teams resist it unless there is a damn good reason for it. This further drives devs and ops apart. They then naturally retreat to their own fortresses, and occasionally sling new releases or operational feedback over each other’s walls.

When does DevOps become needed in your enterprise?

The answer may not be very obvious so let’s look into the impact that a change to DevOps can have on business performance, employee moral and how legacy matters can get in the way.

How DevOps Impacts Business Performance

Does your organization possess:

  • Commercial products that are NOT unique in the market? (think of Windows as unique)

  • Software systems that offer competitive advantage? (keeping competitors at bay)

  • Systems that provide critical business functions? (customer service, logistics, etc.)

If you answered yes to any of these, you probably should give DevOps some serious thought. Real world examples are all around us. Banks with superior online banking services are stealing customers from the laggards. SaaS companies are displacing enterprise systems sold by 800 pound gorillas. Similarly, FedEx and UPS have left the US Postal Service in the dust by leveraging state-of-the-art systems and logistics.

As technology improves and new platforms become available, newcomers seize opportunities to best services provided by incumbents. The ability to constantly adapt to meet market needs is vital. To stand still, even for a while, is suicide by a million cuts. Starting with a slow, but steady decline in market share while competitors grow rapidly.

How DevOps Impacts Employee Morale

A recent report on DevOps and Traditional IT Ops productivity revealed that DevOps oriented teams:

  • don’t fight fires as much and spend less time on administrative support

  • require less time for communication and work fewer days with after-hours

  • claim to work fewer hours each week and spend more time acquiring new skills

Given these observations, its usually only a matter of time before employees seek out opportunities within organizations with better practices, opportunities for self improvement, benefits, and work-life balance.

Don’t Let Legacy Hold Your DevOps Plans Back

If your team or organization maintains a mostly stagnant, legacy system that makes it extremely hard to adopt best practices around, don’t give up. Form a small cross-functional task force, and look for opportunities to streamline the process wherever possible. You’ll know where the benefits outweigh the costs. Start small and do not settle for status quo. The legacy system is bound to be replaced in the near or distant future, so as you kick off other projects, look to start with a clean slate.


Responses (2)

  1. Avatar  


    August 22, 2013 @ 1:58 pm

    Was there a reason behind using GitHub, instead of Atlassian’s Stash product?

  2. Avatar  

    Oliver White

    August 26, 2013 @ 7:02 am

    Not in particular, we just wanted to experiment with other tools out there and expose our readers to as many different technology companies as possible. We also produced a similar report last year with free or OSS tools entitled “Pragmatic Continuous Delivery with Jenkins, Nexus and LiveRebel” — check it out:

RSS feed for comments on this post.

Leave a comment