Software & Web Development

Six ways DevOps is changing the role of IT

The following is a contributed article by Adam Johnson, Vice President of Business and a founding member at San Francisco-headquartered software network virtualization company Midokura.


Years of outsourcing has had a profound effect on IT. In order to get the most economies of scale, IT teams have become cost centers of sorts, carving up functions that are often offshored to third-party outsourcers. Generally, the lowest bidder wins the business. To further streamline management, IT “siloed” itself to mirror the functions delivered by the outsourcers. The intent was that the same team could manage both internal employees and outsourced resources for each function.

One benefit of the modern outsourcing movement is the rise of “specialization”. However, enterprises have to pay a premium for staffing and training these employees. Additionally, these specialists typically have expertise in one specific domain, rather than hold a broader knowledge. The result has been discouragement of agility and innovation.

Today, rapid time-to-market is table stakes for modern IT organizations, and is creating a new shift in the role of IT. Because software needs to be released at an ever-increasing rate, the old “waterfall” develop-test-release cycle is now considered broken. Showstopper or expensive errors are caught too late in the release cycle. The arcane notion of, “that’s not my specialty,” and thereby handing things off to IT to operate or a DBA team to investigate, doesn’t apply to modern IT organizations any longer.

With the advent of the DevOps philosophy and its lean ethos, agility is achieved by close collaboration and cross-pollination between what once were mutually exclusive development, operations and quality assurance (QA) roles. This is now having profound changes to IT in the following six significant ways:


1. Death of the IT specialist, rise of the full-stack, multi-discipline expert

DevOps is turning developers into “full-stack” generalists. Typically, the food chain goes from developers to full-stack developers responsible for the quality of the testing and release environment. The role of the full-stack developer encompasses: programmer, build/release managers, QA, operations analyst, sysadmin and DBA. A developer is well versed in all those functions. But the reverse of the food chain is not possible as, for example, a QA person or a release manager may not have the programming skills to be a developer.

Although from a skills perspective a developer can handle an entire software development process, the pay rate for developers is higher than that of a release manager or a QA professional. A word of caution for managers would be to not overwhelm developers with administrative tasks.


2. Operations is giving way to developers

Operations was once responsible for all environments, overseeing configuration management, Dev/Test, staging, production, even development servers and workstations. Given this, you can only imagine the wait time for Operations to finally get around to a ticket. Consequently, development teams typically lack direct access or insight into production, as they must obtain permission from Operations. If a developer needs different versions of a library than the one available to do their job, often times this requires a long wait with helpdesk.

On top of this, developers have no real flexibility to try out new services, change backends for an application (such as from MySQL to MongoDB) or optimize application performance without engaging Operations. But DevOps is changing this. Configuration management tools such as Puppet or Chef, for example, are making it possible for developers to do all of these tasks independently without submitting a single service ticket in IT and playing the wait game for service provisioning. This gives developers the freedom to choose the combinations of technologies to support their applications stack without having to make tradeoffs when using a prescribed, integrated development environment (IDE) or architecture.


3. Reporting structures are being remapped

In the past, developers would report to engineer or software development to work as a shared resource. This model was inherently contentious. Nowadays, more DevOps teams report to different lines of an organization, meaning that their skills can help develop software to create new lines of business and drive revenue. Best practices are likely shared within the organization, however, actual personnel generally are not.


4. DevOps is pushing for in-sourcing

In new projects where use cases are still being defined and assumptions are still being challenged, agile software development is most effective as it encourages experimentation and piloting.

However, the downside is that with continuous integration and continuous delivery (CI/CD), it is difficult to cleanly parse out pieces of a project to outsource. In the meantime, third-party outsourcers bid for projects with flat fees. Tending to be more risk-averse, they bid with repeatable solutions, as no organization would pay a third-party outsourcer billable hours to experiment and find better alternatives.

In turn, IT organizations have discovered that the development of transformational technology cannot be outsourced. Many organizations are finally recognizing the value IT brings to the table as a revenue generator rather than a cost center. The consensus is that it doesn’t make sense to give up ownership of such valuable tech-enabled services to expose an organization to potentially being copied by the competition. IT organizations are therefore increasingly moving towards in-sourcing projects that offer an opportunity to transform the business. 


5. DevOps is changing procurement

In environments with undefined requirements and high parallel experimentation, the typical RFP process just doesn’t work. DevOps teams are not convinced by glossy brochures or sales pitches as they must experience something first-hand before truly believing in its value. Vendors seeking buy-in from a DevOps organization must be willing to provide a proof-of concept to verify value.

Open-source software helps accelerate evaluation without the red tape. In contrast to open source, proprietary software always requires signing a legal agreement, even for evaluation. Open source removes the obstacles for trying out software for an individual or an organization. Evaluators get to try out the software with use cases relevant for their work and once they are ready to go into production, it is easier to convert a user to a customer because the value has already been established during their own evaluation.


6. Creating decision makers at every level

Finally, DevOps has turned the role of the decision maker upside down. Traditional IT is top-down, whereas decisions are now largely driven from the bottom up. Previously, new software purchases were based on financial calculations. Vendor discounting was based on volume, meaning organizations often loaded up shelfware for deep discounts.

These days, as DevOps takes control of an increasing part of the environment, IT decisions can be driven from anywhere within the organization. DevOps and agile practitioners could be anyone - from developers, DevOps managers, build/automation managers, site reliability managers, to architects. The influence is widespread, driving purchasing the decisions from the middle - or even from the bottom - to the top.


IT of the future

Software is seen as the key to innovation. As the competition becomes more and more fierce, fast moving organizations move the market requirements from “unmet need” to “must-haves” -- wrestling the market from incumbents that never addressed the “unmet need” in the first place. Uber, Square, AirBnB, Netflix are examples in their respective categories.

There are two types of organizations; one that is willing to break the old established way of doing things in exchange for agility and innovation, and the other that is trying to drive towards maximizing efficiency in their existing way of doing things. However, doing the wrong things faster won’t help the organizations compete against the fast-moving companies that are trying to displace the incumbents.

This means that professionals working in these organizations have to keep up with the technical skills of tomorrow. However, decisions as to how operations are run are top-level decisions. Individuals seeking to gain sought after skills may not be able to transfer to the areas where the leading innovations are taking place.

One of the ways to future-proof one’s career is through open source. Contributions into open source provide the individuals with access to the tech and more importantly to the network of people globally. With bleeding-edge technology that is constantly evolving, training programs will fall behind the technology and the only way to become trained is to become an active participant. There are many ways to contribute to open source that do not involve programming. Evangelism and benchmarking are just two examples.

Consider this an open invitation to join the open source revolution.


« Rant: The bland tedium of unsolicited crowdsourced opinion


VideoShot: The many names of Satoshi Nakamoto »
IDG Connect

IDG Connect tackles the tech stories that matter to you

  • Mail


Do you think your smartphone is making you a workaholic?