CI Tools and Best Practices in the Cloud

Continuous Integration

Subscribe to Continuous Integration: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Continuous Integration: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Continuous Integration Authors: Jason Bloomberg, Yeshim Deniz, Elizabeth White, Pat Romanski, Liz McMillan

Related Topics: Compliance Journal, Continuous Integration, DevOps Journal

Blog Post

Compliance in Enterprise DevOps By @Datical | @DevOpsSummit [#DevOps]

Exploring the Concept of "Compliance as Code"

Can Regulatory Compliance Be Automated in Enterprise DevOps?

George Hulme wrote an article today relating an interview he conducted with Justin Arbuckle, chief enterprise architect at Chef, discussing the concept of "compliance as code" as it relates to DevOps practices in large enterprises (see article here).  It probably comes as no surprise, but the enterprise labors under a heavy regulatory burden, made more so over the past decade with new regulations like Sarbanes-Oxley and Dodd-Frank. Uncertainty in the current macroeconomic environment and the proliferation of security threats imply that it is likely there will be more regulation to come in the near future.

At first glance, it might seem that the goals of DevOps and regulatory compliance are inherently at odds.  Whereas much of the buzz around DevOps advocates delivering software at dizzying rates, compliance and security are concerned with proper oversight of the change management process to ensure that the enterprise isn't opening itself up to potential vulnerabilities.  With the tedious amount of rules and regulations that enterprises are subjected to, compliance can end up being a governor on the release process, defeating the potential benefits from adopting DevOps practices.

Remember, though, that security and compliance are one of the central themes in The Phoenix Project by Gene Kim, a business novel that is considered one of the leading thought pieces on the DevOps philosophy.  The CISO is a major character in the novel, and himself embarks on a DevOps journey where he eventually learns that by eliminating redundancy and waste in his policies, and by shifting security and compliance concerns left in the release cycle so they are addressed from the requirements stage on, he could remove the compliance bottleneck and actually better support the fast delivery of high quality, stable, and secure software.  And at its heart, this is what DevOps is really about - not advanced techniques like Continuous Delivery, but rather collaboration among all of the key stakeholders to form a holistic view of the entire software value chain.

Arbuckle's concept of "compliance as code" agrees with Gene Kim's point of view.  What he advocates is a "big paradigm shift for compliance people inside organizations, [so that you can] start being able to express those compliance requirements in a form that's codable.  Using something like Chef for instance what we're able to do is we're able to specify a particular policy in a way that is automatable.  In a way that we know is always going to be implemented every single time."

His advice in terms of achieving "compliance as code" begins first with knowing what to automate - "... the difficulty at large enterprises has actually less to do with the tools and more to do with knowing what you want to automate.  Knowing what you actually want to put in infrastructure as code."  This is a prime example of why compliance and security issues need to be addressed during the requirements stage, to ensure that quality and compliance are baked into the product from the very beginning.  From there, the adoption of Agile methodologies like test-driven development and automated testing facilitate the execution of translating security and compliance requirements into code.  According to Arbuckle, you don't have to try to eat the entire elephant at once using this approach, as "the great thing about tests is they are additive," allowing your organization to build up a library of security and compliance tests over time.  Embracing this kind of mindset removes the potential friction between the  security/compliance and DevOps teams, instead bringing them together to form a single team focused on achieving organizational objectives like Continuous Delivery.

This concept of "compliance as code" dovetails nicely with Datical's latest innovation for the database in the release of Datical DB V3.0, a powerful and fully customizable Rules Engine which allows enterprise DBAs to fully automate the process of validating database changes.  Customizable rules allows each organization to codify its own unique compliance and security policies, as well as best practices in database change management.  For the enterprise DBA team, as much as 70% of their productivity can be spent on tedious manual tasks like creating and validating database changes, limiting their ability to support the organization's drive towards adoption of Agile development methodologies and DevOps practices.  With Datical DB and Rules Engine, the DBA team can remove themselves from the trenches and take their rightful place as field marshals, governing the battle at the strategic level while Datical DB automates the tactical.  All while providing the visibility and risk mitigation needed to keep the DBA team firmly in control, and able to safely support the enterprise's drive towards Continuous Delivery.

More Stories By Rex Morrow

Rex is the Marketing Director at Datical, a venture-backed software company whose solution, Datical DB, manages and simplifies database schema change management in support of high velocity application releases. Prior to Datical, Rex co-founded Texas Venture Labs, a startup accelerator at the University of Texas, and received his MBA from the McCombs School of Business. Before graduate school, Rex served as a Captain in the U.S. Army, and was awarded two bronze stars during combat deployments in Iraq.