Bill Dickenson, Independent Consultant, Strategy On The Web
DevOps brings both the developers and operations processes into alignment. This blog focuses on what operations should expect from the developers while my next blog will focus on what developers should expect from Operations. Managing both sides is essential to a successful flow.
One of the major weaknesses in application development is that while software only delivers value when it is running, few universities or professional training organizations focus on how to make software operate smoothly. To be successful, software must operate efficently on the target platform, handle exceptions without intervention, and be easily changed while remaining secure. Security may sound like an odd addition here but studies continue to validate that many violations in security are at the application level. It must deliver the functionality at the lowest cost possible. CISQ has evolved a set of quality characteristic measures that when combined with automated software tools, provide a way to make sure that the code delivered, delivers. Operations has every reason to expect that software will be delivered with these characteristics.
Setting SLA Measurements for Structural Quality Characteristics
CISQ recommends the following four OMG standard measures engineered into the DevOps process. CISQ measures for Security, Reliability, Performance Efficiency, and Maintainability were developed by representatives from 24 CISQ member companies that included large IT organizations, software service providers, and software technology vendors.
1) Security Violations per Automated Function Point
The MITRE Common Weakness Enumeration (CWE) database contains very clear guidance on unacceptable coding practices. Delivered code should not violate any of these practices however the top 22 are considered the most egregious. They place an unreasonable burden on the infrastructure to protect. Operations cannot plug the leaks between modules where the security issues occur. The CISQ Security measure covers the Top 22 CWEs.
2) Reliability below 0.1 violations per Automated Function Point
In any code there are data conditions that could cause the code to break in a way that allows an antagonist to gain access to the system. These also cause delivery failures in the expected functionality of the code. Reliability can be measured as weaknesses in the code that can cause outages, data corruption, or unexpected behaviors. The CISQ Reliability measure is composed from 29 severe violations of good architectural and coding practice that can cause applications to behave unreliably.
3) Performance Efficiency below 1.0 violations per Automated Function Point
Performance Efficiency measures how efficiently the application performs or uses resources such as processor or memory capacity. Performance Efficiency is measured as weaknesses in the code base that cause performance degradation or excessive processor or memory use. This has been operationalized in the CISQ Performance Efficiency measure. In today’s relatively cheap hardware environment, violations of this have become common. Unfortunately, they also degrade the cloud readiness.
4) Maintainability violations below 3.0 per Automated Function Point
As code becomes more complex, the change effort to adapt to evolving requirements also increases. Organizations that focus on Maintainability have a lower cost to operate, faster response to change, and a higher return on investment for operating costs. Up to 50% of maintenance effort is spent understanding the code before modification. The CISQ Maintainability measure is composed from 20 severe violations of good architectural and coding practice that make code unnecessarily complex.
These 4 are the minimum requirements that operations should expect from developers. In the next blog we will discuss what developers should require from operations!