Brian Jackson - Fotolia
DevOps isn't easy: It can be a struggle to implement and manage successfully. A DevOps assessment will tell you if the business and its IT organization are ready to make changes.
The rapid cycle times embraced by the DevOps software development and deployment methodology allow businesses to capture opportunities faster than traditional software development approaches. Small, incremental changes with DevOps mean that a business can try new ideas, take more risks -- even fail without dire consequences, which are some of the reasons why it has supplanted traditional waterfall-style development.
While DevOps has proven effective for accelerating software development and streamlining the interaction of operations and quality assurance (QA) teams, it also imposes demands that every organization must be ready to address. Answer these five questions to perform a realistic DevOps assessment before making the shift.
1. Does DevOps bring value to the business?
Consider long-term project returns. Traditional software development cycles take years of coding and testing before a release candidate is ready for distribution. This commits a tremendous amount of labor to a product when sales are not guaranteed. Issues such as defects and oversights in the release -- bugs -- and competition potentially erode the return on this investment.
DevOps changes the business implications of software development by implementing smaller, shorter development and release cycles. Developers, quality assurance and operations staff work constantly on parts of the product's continuous release pipeline. Each release adds meaningful features and functionality to the product. It gets to market faster, avoiding that long, risky investment period.
2. Is IT flexible enough to support DevOps?
The IT organization must deploy each small, rapid software release. This means installing the new application version on one or more servers in the data center or cloud, and interconnecting supporting databases, storage, performance monitoring and other resources. These activities are core functions of IT administrators; what's new is the pace of change that DevOps sets, which may tax traditional operations processes.
The traditional siloed processes to provision and deploy a typical enterprise application take months. The IT organization determines application requirements; specifies requisitions and approves new servers and other equipment; acquires OS and other software licenses; installs any new gear; and actually performs the deployment for the approved release candidate. There is little if any interaction with developers during this effort.
Such rigid processes work fine when the IT staff works on occasional software releases, but implementation strategies quickly become overwhelmed and collapse when the team deploys a new application version each month, or several times per month.
The move to DevOps must involve more than just a new development cycle. In your DevOps assessment, consider how the current IT team would function if maintained as-is and how it would change. IT works and interacts with developers and QA staff differently in a DevOps shop to provide storage, computing and networking resources on a much faster timetable to test and support each new release.
3. Is the company large enough for DevOps?
DevOps only works when there is a cyclical pipeline of development, testing and deployment filled by one or more software development project. Gaps in the pipeline leave staff sitting idle.
The move to DevOps demands an organization large enough to support the staff, processes and tools that keep DevOps productive. Balancing staff and project demands can be startlingly difficult for small businesses -- perhaps up to 250 people -- where the costs of talent significantly affect the overall budget. Small businesses often subcontract application development or invest in packaged applications, such as Salesforce rather than an in-house customer relationship management package.
Filling and maintaining a DevOps pipeline usually involves a larger organization which is better able to acquire and adjust staffing levels to meet project timeline demands. Companies with 250 to 1,000 people may be better able to integrate a DevOps process, and businesses with more than 1,000 people may well have the scale needed to embrace and leverage a DevOps strategy.
4. Does the company know its DevOps strategy?
DevOps isn't a single initiative or event -- you won't successfully implement DevOps with one software tool or one plan laid out in a book. DevOps is an amalgam of people, tools and processes.
It takes talented developers, relentless testers and knowledgeable operations personnel. It takes automation, workflow, collaboration and related tools. It takes dynamic and flexible business processes to eradicate traditional silos and get multiple teams working together. With all these elements, DevOps dramatically accelerates software development and deployment cycles and brings tangible benefits.
Every company adopts DevOps differently, adjusting and adapting the people, tools and processes to meet the organization's unique goals. This means hiring developers familiar with DevOps cycles and workflows, organizing an IT staff capable of accommodating dynamic release schedules, implementing a suite of tools that facilitate collaboration between developers, QA and IT, and applying clear business leadership that can drive DevOps adoption
For most fledgling adopters, DevOps is not an all-or-nothing endeavor. Organizations often assess DevOps' potential and adopt it by slow degrees, building expertise with groups working on small, low-priority projects and then systematically bringing those skills and tools to bear on more critical projects over time.
To join an IT organization already invested in the DevOps methodology, or ready to embark on a DevOps path, brush up on these interview questions.
5. Can the company commit to constant change?
Implementing a DevOps strategy is not a one-time effort, and organizations must constantly adjust strategies to deal with business changes, technological advancements and even evolving user expectations. After the initial DevOps move, an organization will face a new development language; migrate to another DevOps workflow and collaboration platform; upgrade servers, implement a private cloud or migrate to a public cloud; embrace a wider scope of client devices -- such as software for tablets and smartphones; and even experience a change in business environment and priorities. Optimizing and adjusting the DevOps methodology and tools is an ongoing responsibility.
Target shares its Red-Hat-enabled DevOps conversion
Inside Facebook's DevOps journey
DevOps pays off -- with effort -- for insurance company