BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
It is the nightmare of any IT project manager or application architect who has invested heavily in a high-profile project, only to see it fail at production time because of non-functional requirements such as performance or scalability issues. What appeared to be a well-developed application moved seamlessly through the majority of the application lifecycle management (ALM) process, then died. Or perhaps the scenario is even worse, with an actual deployed application exposing privileged data haphazardly and without adequate security constraints.
With strong development and operations teams working together in a manner that is true to the unified DevOps approach to application development, deployment and runtime management, these issues can be avoided, and application lifecycle management can be greatly simplified. Often, however, a divide between what DevOps should be doing and what is really happening in day-to-day operations is a problem.
Development and operations together at last?
DevOps is a chimera that was created to address the strategic demand side as well as the vast ocean of operational demands in software initiatives. It was supposed to bring together the two disparate factions of operations and development so they could work together and efficiently build and deploy better software. DevOps has a foot in both worlds and is ideally positioned to find the connections and commonalities between the two cultures. From there, it is possible to define and create standards that integrate both ITIL (Information Technology Infrastructure Library) and CMMI (Capability Maturity Model Integration). With everyone thinking about problems in the same way and trying to solve them using a common strategy, the process improves.
Too little, too late
Unfortunately, many IT shops still do development first and operations second. There is no unified DevOps, and when an organization waits until near the end of the development process to even start thinking about performance and security, the costs go way up, as do the risks.
Don Brancato, an enterprise architect with Hewlett-Packard Co., puts it simply, "When you tack on quality and security after a product is made, the costs are high. You also risk not being able to go to market on time. When nonfunctional issues are addressed on the design side, developers can write code to meet those requirements. It actually costs much less."
Can unified DevOps be agile if they do things right?
But with the ever-increasing pressure to push products to market faster and faster, is it really practical, let alone possible, to incorporate the operations view into the design phase, especially for organizations that employ an Agile-based approach to application development and deployment?
Brancato says there's no reason why proper planning should slow down Agile or Scrum processes. There is already a body of information regarding nonfunctional requirements that teams can rely on, including policies, procedures, regulations and guidelines for each industry vertical. "Having a dictionary of nonfunctional requirements on hand doesn't violate any of the principles of Scrum," he said. "We know that those things exist. They have to be covered, someone has to do that work, and it has to be covered by the sprints before the product is released."
It doesn't violate Scrum principles to refer to a library of regulations or a dictionary of industry standards during planning, development, Scrum sprints or deployment.
When unified DevOps is done correctly, the benefits can be positively quantifiable. By writing the right type of code, that is, code that is aware and consistent with nonfunctional requirements, that code can be used over and over in future products.
"The process is cost-effective," said Brancato. "I expect the better performing shops to experience a 35% reuse of code, if that code was originally written in a secure fashion," decreasing costs, cutting development time, reducing the risk of late failure in production or post-production, and ensuring a quality product that meets the expectations and requirements of both development and operations. And when all of this happens, an organization knows that its application developers, operations management team and the people managing the ALM process are doing DevOps right.