Software developers are making business decisions for you every day. The code they write determines the safety, security, performance and reliability of the software that drives the business, giving them the power to introduce or minimize risks. The software developers make serves as the organization’s primary interface to the customer.

By allowing developers to make critical business decisions related to the software managers, directors and C-level executives have delegated an extraordinarily high level of business responsibility to the developers. Their decisions directly affect immediate or future success, growth, damages or liabilities, as well as the stability of business leadership positions. The relationship between business outcomes, the interaction between business and development personnel, and the software code cannot and should not be understated.

 The key to reining in these risks is to align software development activities with your organization’s business goals. This can be achieved through “policy-driven development,” which ensures that engineers deliver software according to your expectations. Policy-driven development involves clearly defining expectations and documenting them in understandable polices, training the engineers on the business objectives driving those policies, and monitoring policy adherence in an automated, unobtrusive way.

Integrating these principles into the development process gives businesses the ability to accurately and objectively measure productivity and application quality. The result is lower cost over the total software development life cycle from build to support, as well as reduced risk.

Adopting a policy-driven development process is key for achieving the following goals:
• Ensuring that engineers don’t make tradeoffs that potentially compromise reliability and performance.
• Ensuring that engineers build security into the application, safeguarding it from potential attacks.
• Preventing defects that could result in costly recalls, litigation or a damaged market position.
• Accurately and consistently applying quality processes.
• Gaining the traceability and auditability required to ensure continued policy compliance.

How does policy-driven development work?
There are five steps in the process:
1. Management defines expectations for how software is written and tested.
2. Engineers are trained on how the expectations relate to the business objectives.
3. An automation infrastructure sits in the background of the development environment to automatically monitor compliance according to defined expectations. For example, a policy may require all code to follow a designated set of secure development practices, undergo peer review, and be verified by at least one test case.
4. When requirements are implemented, the automation infrastructure unobtrusively identifies policy violations.
5. If policy violations are identified, the infrastructure alerts the responsible engineer that policy violations need to be addressed immediately.

The ability to passively and unobtrusively monitor engineers’ work is paramount to policy-driven development. If it is done properly, you will improve quality, increase productivity, lower development life-cycle costs from build to support, and reduce risks.
Elevating guidelines to policies
Many businesses traditionally view software development as a creative art that should be uninhibited by business-related policies. To this end, organizations have kept business processes on one side of the house and production on the other. But the fact of the matter is that the two are inseparable. Software engineers are making business decisions line by line as they develop, test and deploy software. As such, it is appropriate, even necessary, that those in leadership positions answer the following question: How well do the engineers understand the business objectives driving the software they are developing?

Most organizations have guidelines for how they want their software to be developed, but a few barriers prevent these guidelines from truly being enforced and consistently followed: