Initially the DevOps movement stemmed from the agile, innovative, born-on-the-web companies who were able to change their way of working quickly. However, the principles and practices are completely transferrable to all organisation types. This includes those at the other end of the spectrum – where processes are very tightly controlled and regulation dictates a significant part of the business investment.

.

Why highly regulated companies initially resisted DevOps

When DevOps first emerged, the major concerns for companies following strict regulations were to maintain their security controls and governance processes. Deploying changes more frequently was viewed as a risk to security and the governance controls which were firmly in place.
Another reason for not moving towards a DevOps way of working was the “segregation of duties” requirement, making it impossible for developers to deploy into production – thereby not being able to “do” DevOps.

.

‘Is DevOps really worth it?’

There were established, formalised processes in place which satisfied all the regulatory needs. For some organisations, it seemed like making any changes to these processes would be more work than what would be saved by automation. This meant that the processes stagnated and hindered future change.

Despite this, the majority of executives now believe that DevOps is a crucial ingredient in making sure that their company can adhere to new regulations and stay ahead of their competitors in compliance adoption.

.

Why DevOps is actually better for highly regulated industries

DevOps can be your biggest ally when it comes to regulation and compliance – as long as you follow a few simple rules:

.

1. View auditors (regulators) as stakeholders in the DevOps journey.

By collaborating with the auditors in the same way as other stakeholders, you can engage with them early in the process and ensure details get agreed upon without costly change further down the line.Getting buy-in from auditors on any technical solutions at an early stage reduces the likelihood of change requests, missed deadlines, and non-compliance. By working closely with auditors, you will ensure that the company has a strong understanding of the level of compliance needed for each different aspect or component of their systems. This helps avoid the waste of being compliant in areas which are not necessary.

Sometimes you will only be able to clearly interpret a regulation through close collaboration with auditors. This avoids misunderstanding and unnecessary rework. In some cases, working closely with the regulatory body can highlight aspects which had not previously been addressed, developing a feedback loop with them. This evolving feedback means that the company will end up with a solution which is satisfactory.

Close collaboration with auditors increases trust in the processes which have been developed in your organisation.

.

2. Codify compliance requirements and policies.

Good DevOps processes will increase the amount of audit trails and governance in the process, while enabling fine-grained traceability throughout the entire delivery process. Compliance documentation can be enforced more easily as part of projects. There is generally less need for process documentation as so many tools now automatically generate any documentation required. By using collaborative sharing tools we can also reduce the problem of different document versions.

.

3. Automate your delivery pipeline end-to-end.

Automation gives reliability, repeatability, and traceability. Automation means we have a predictable outcome and fewer manual processes, which is good for auditing and tight control.By having fewer manual tasks, we can also reduce the possibility of manual error and missed processes. Automated environment provisioning improves the quality of testing and gives a high level of confidence in the change.

With end-to-end automation and process orchestration, controls are written in and embedded to processes and systems. This helps to reduce liability. Systems are designed to reduce the risk of individuals making errors, forgetting processes intricacies, or even taking malicious action. This also helps to develop a blameless culture. Bullet-proof processes means that security protocols now become built-in. Rather than see DevOps as a threat to security, it is now being viewed as the best way to mitigate risk. It also becomes a way of enforcing security, audit and compliance requirements.

Automation in all areas allows you to quickly evolve with changing regulation requirements and last-minute additions, helping you to stay ahead of your competitors who aren’t able to do that. Future regulation is likely to require reporting on the lowest-level processes, and the only way to ensure that processes are being followed reliably every time is to introduce automation, and DevOps – a culture of ongoing improvement.

.

What is happening now

Some of these companies in highly regulated industries are actually starting to lead the curve in terms of innovation and DevOps adoption now. They have seen just how powerful DevOps can be and are creating an agile business which can meet regulatory requirements and evolve with customer needs – making their business much more competitive.

.

Learn More

To discover more about how Sandhata can help you achieve DevOps success, take a look at our DevOps brochure.

The post Does DevOps Work in Highly Regulated Industries? appeared first on Sandhata.

What DevOps is NOT

I would like to share with you a few of my thoughts on what DevOps is NOT. Hopefully this will help you to keep focused on the primary message of DevOps and result in better ROI throughout your journey.

1. It is not an end goal.

There is no logical end state to DevOps as each organisation is operating in an evolving customer market. For businesses to stay competitive, they need to grow and change. DevOps is a great way to make your business more agile and seize opportunities, but tools and processes will always need to change and improve to remain fit for purpose.

2. It is not a body of knowledge.

There is no “right way” to implement DevOps in your organisation. DevOps provides the principles and highlights the goal – Business Value – which everyone should focus on. Each organisation has different challenges and takes a different path along their DevOps journey, which can all be valid.

3. A DevOps solution cannot be bought off the shelf from a vendor.

There are vendors now who are offering a full DevOps toolset, and that is great because the tools will likely integrate well together and can help to give you a joined up pipeline. However, just incorporating the tools does not mean that you are doing DevOps, it is just the first step. To really reap benefits of DevOps in the long term, you need to embrace collaboration and ensure that the tools you have chosen are fit for purpose and adding efficiency to your processes. It is very easy to use the right toolset in the wrong way, or simply to not get the maximum benefit out of it!

4. It is not sacrificing governance and compliance.

In fact, DevOps can be a real enabler for more efficient, more effective governance and compliance. The automation and streamlining processes which are part of DevOps help to focus the governance and compliance requirements and usually enable more thorough auditing.

5. It is not just automation.

If you have automated part of your delivery pipeline then that’s great, and its (probably) going to add value to your team, however there are so many aspects of DevOps which work with the automation to multiply the benefits. It is quite easy (and common) to have automated processes, but some of those processes will not have been streamlined and are actually wasteful / unnecessary. In cases like this, automation just hides the waste more effectively, but it is still there.

6. It is not just a toolset.

Using Jenkins to do CI is great, but that doesn’t mean that you have got DevOps. It’s a small part of a big journey, and you need to remember that continuous improvement is key to DevOps, so your CI strategy needs to evolve to make sure that you are continuing to meet your business goals and deliver for your teams. This means that stagnating with an embedded tool generally in not in line with DevOps.

7. It is not “using Cloud”.

Cloud is a great thing which has the power to transform your IT capability, but just using the cloud doesn’t mean that you are realising any of the potential benefits of proper DevOps.

8. It does not mean that anyone can release any change to production at any time.

Releases should be entirely in line with the business needs. Having a streamlined, highly automated delivery pipeline enables you to release changes quickly. Releases can then be easily aligned with business needs to provide maximum business value and reduce unnecessary work and wastage.

9. It is not a separate team or organisational unit.

DevOps, at its heart, is about removing silos not creating additional ones. Having a separate team to kick-start the process, come up with a strategy and adoption guidelines is a valid way of embarking on this journey. However, the “DevOps team” should be a short term measure with a view of dismantling the team once the goals have been defined and progress is being made across the organisation.

10. It is not combining the Development and Operations team and leaving it at that.

Real value won’t materialise unless changes are implemented in ways of working on the ground. A thorough and interesting article about how teams can be structured when embracing DevOps is featured on the DevOps Topologies website.

11. It is not replacing or removing Ops.

Similarly, DevOps does not mean that developers are suddenly responsible for supporting their own code in production. Operations do continue to have a very big role: they also take principles from DevOps to implement Lean practices, streamline their work tasks with an eye on business value, as well as automating tasks where appropriate. Successful DevOps means that the Dev and Ops teams have THE SAME BUSINESS GOALS. This is such an important point as traditionally the objectives of the Dev and Ops teams were at odds with each other, but they need to be aligned for the journey to be successful.

Summary

To finish on a positive note, let’s bear in mind the key things that DevOps IS:

It challenges the status quo.

By adopting a change in mindset, you are able to analyse what really adds value for your business. The pieces that are left over are simply waste.

It is a culture shift.

DevOps brings a culture shift that spreads across the whole organisation. It radically changes the way we work and engage with each other, to become more collaborative and responsive to change.

I hope this has helped your understanding of the DevOps principles and how they can improve your organisation.

Good luck on your journey!

The post What DevOps is NOT appeared first on Sandhata.

Want to know more?

Discover the Sandhata approach to DevOps and how we can support you by improving your ability to innovate and stay competitive.

The post DevOps Myths – Debunked! appeared first on Sandhata.

Life without DevOps

Most large enterprises live by formal governance processes. These are in place to police the software delivery and ensure that all deliverables follow the organisation’s standards in terms of security, design, architecture, and reusability.
Although these processes are designed to safeguard the business and keep the delivery on track, they do present a series of hoops to jump through – requiring additional time and work for each delivery.

These formal governance processes often include:

• Checklists to be completed at different stages of the project
• Workflow approval on documents – often using collaborative platforms
• Meeting with participants from various teams to discuss one aspect of the delivery in detail
• SOA governance meetings to get formal architect sign-off on the design

Why are these processes needed?
Without any kind of DevOps strategy, businesses need processes like these in order to catch any deviations from slipping through the net. The checkpoints are used to maintain stakeholders’ trust in the delivery process. However, even the strictest governance processes can’t fully prevent issues from occurring.

The illusion of collaboration
In a typical business, collaboration only happens when people from different teams sit down together in a meeting. All other collaboration outside of the meeting room becomes optional. This means that people often rely on these meetings to the point where they are seen as the only opportunity for collaboration and communication across the departmental borders. This can in turn cause team members to treat the meetings as a safety net where any issues get picked up, which means they become less focused on proactive improvement.

How DevOps can help

DevOps often involves automation of large parts of the value chain. This helps the organisation to improve the speed and quality of software delivery while also automating the required governance and control processes along the way.

DevOps makes the right thing to do the easy thing to do.

Automation is a powerful way to reduce risk, ensure compliance, and maintain governance. It can restrict access to certain systems through ‘known-good processes,’ to ensure all activity follows the standards and compliance requirements. It also provides an audit trail for governance and reporting.

With the help of DevOps you will also be able to eliminate any unnecessary processes in the business so that you don’t waste time or effort on governance you don’t need.

Life after DevOps Adoption

Once you have put DevOps processes into practice and established a collaborative culture across the business, your team members will naturally have a much higher level of trust in the delivery process and quality. This will in turn lead to less resistance to change from within and outside the team. The shared goal of all team members becomes the same: to deliver more business value faster.

Fewer hoops means faster delivery
Once you have implemented your DevOps strategy and your value chain has been streamlined, there is very little or no benefit to having the same set of formal governance processes which were previously in place. Any of these extra tasks and meetings would just mean unnecessary admin and overheads, slowing down the overall delivery. With an active DevOps culture, many of the manual, labour intensive governance tasks – such as checklists and formal SOA governance meetings – are simply no longer needed.

The culture shift
You will be able to see a cultural difference in the teams implementing DevOps, compared to those who are not. Teams following DevOps practices generally take on an attitude of proactivity and ownership, without relying on formal processes and checklists to catch any issues. Although this puts more responsibility in the hands of the individual, you will also see that an established DevOps-minded team will have standards in place which make the right thing the easy thing to do.

The cultural change is an important factor. It’s crucial that all team members feel comfortable with the new responsibility and the new processes. To the outside observer, there will be fewer controls, fewer formal approval meetings and fewer hoops to jump through. However, the governance is still very much alive – it has simply been moved under the surface.

Learn more
Want to know more about how your organisation can remain fully compliant with industry regulations, while adopting a DevOps strategy for faster and better delivery? Download our service brief: The Sandhata DevOps Approach.

The post How DevOps can improve your Governance appeared first on Sandhata.