Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Defining DevOps: 6 key attributes everyone should understand

public://pictures/Phil-Simon-Speaker-Author.png
Phil Simon Speaker/Author, PhilSimon.com
 

The history of IT projects in the pre-DevOps era is littered with massive and often very public failures, most notably the Healthcare.gov debacle. The odds are that you have personal experience with at least one ill-advised project. After all, statistics show that more than three in five IT projects will exceed the budget, fail to deliver on the agreed upon functionality, take longer than expected, cause major business problems after activation, or combine two or more of those scenarios.

It's not hard to find extensive analyses of IT project failures. IAG Consulting published a fairly extensive study of failures a few years back, and I wrote a book on the subject.

At the risk of grossly simplifying, IT projects rarely fail because of actual bugs or technical glitches. Almost invariably, the problem is human, cultural, or organizational. It can happen when key employees blow off or can't attend a training class because their "real jobs" understandably get in the way. Then there are oodles of potentially show-stopping data issues that turn up only after project plans have been created. Toss in software vendors, consulting firms, and other third parties with their own agendas, then add shrinking IT budgets coinciding with the financial crisis, and your garden-variety IT project is a recipe for disaster.

IT failures are particularly endemic when the waterfall method is involved. For instance, let's say that someone forgets to capture a key business requirement during the discovery process, but no one notices until the organization has reached the point of no return. The longer it takes to catch the omission, the more expensive the fix.

A better way to understand DevOps

Against this backdrop, something had to give—and it has. In the last five years, we've seen the rise of both agile software development methods and DevOps. Rather than thinking of these terms as separate and distinct, though, it's more helpful to view them as counterparts.

Because agile methods go back 15 years, they're generally better understood. But the same cannot be said about DevOps. A proper and easily understood definition of the term is essential but often sorely lacking. There's a great deal of confusion out there. Consider the following:

  1. It's not just another moniker for the traditional "IT department." Is there overlap? Of course, but this isn't just a matter of nomenclature.
  2. It requires new skills—and old ones. To be effective, DevOps team members can't mimic the communication skills of Milton from Office Space.
  3. It's fundamentally cross-disciplinary. This isn't just about being "good with computers." Team members need to bridge the IT-business divide, get out of their traditional silos, and work effectively with employees in the different lines of business. That means understanding business needs, not just hardware requirements.
  4. It's fundamentally inclusive. DevOps staff typically includes systems engineers, system administrators, operations staff, database administrators, network engineers, quality assurance (QA) folks, security professionals, and others.
  5. The DevOps mindset needs to shift from discrete IT projects to ongoing relationships. Development is never finished.
  6. The presence of DevOps guarantees nothing. It's not a panacea. No single group can fix a dysfunctional organizational culture.

Equipped with a greater understanding of DevOps and how it has evolved, we can now delve into the best way to avoid repeating the same project management mistakes of prior decades. To make that happen, you need to communicate clearly. I'll talk more about that next time.

Keep learning

Read more articles about: App Dev & TestingTesting