Conway’s Law and DevSecOps: How communication affects security

Conway’s Law describes how companies develop software. Broadly speaking, it means that software projects tend to be designed and delivered based on the same approach that a company takes to communicating internally. Conway’s Law is quoted as:

Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.

Today, we have seen DevOps and DevSecOps get adopted more readily in organizations. So will security teams find that their own approaches to keeping their companies secure will be affected by company communications models too?

Conway’s Law … is it more of a guideline today?

The first element to consider here is how Conway’s Law measures up today. Is it still true as it was in the past, and if so, why? 

The first point to consider is how many different types of software development team exist and in what industries. For sectors like finance — traditionally one of the most heavily regulated and security conscious sectors — the growth of challenger banks has affected the whole sector.

[Read: How DevOps and security teams can get along better]

According to CB Insights, around $8.3 billion of funding went to new FinTech startups and challenger banks in Q2 2019, 50 percent higher than the same quarter a year previously. These organizations have taken up agile software development approaches from the start so they could launch quickly, attract customers and grow the number of services they offer over time. 

At the same time, high street banks have begun adopting cloud and DevOps in order to remain competitive with these new market entrants. These changes have been accompanied by a desire to move faster and keep up with consumer demands. Both new and established companies in this sector rely on their applications and software development processes to be competitive and to appeal to customers.

These consumers expect to be able to interact with their banks in real time, over multiple channels, and use their data in new ways to help them. These communication channels are faster and more interactive than traditional banking could support, and this has led to changes around communication internally to reflect this.

So, you can argue that these changes in communication approaches internally took place in tandem with changes in software development. While external market conditions drove the changes that have taken place in this sector, Conway’s Law would still seem to apply across both communication and software development mirroring each other.

At the same time, there are other sectors that are much slower to adopt new software development methods. For industries with process control or operational technology implementations in place, like manufacturing and pharmaceuticals, the emphasis on compliance and control for these organizations puts more structure on to software development processes.

Where Conway’s Law still applies is that the clarity of communication around specific needs is essential – for companies with complex compliance rules to follow, any complication in communication will slow down software development too.

What does matter here is that communications approaches within companies can still affect the design and build of that software over time, as was the case when Conway’s Law was first suggested. However, the increasing importance of IT and applications within businesses today means that there is more emphasis on getting software development right over time, leading to more change in processes around software too.

Adopting DevSecOps and better communication

The ability to create new software, package it, and get it into production faster has been a significant achievement for developers, but IT security teams have had to face more updates and more potential risk.

At the same time as DevOps processes have been adopted, there has been an increase in regulation around security and privacy for data. The European Union’s General Data Protection Regulation (GDPR) led the way, but other new regulations based on the same approaches have been drafted around the world. 

For security teams concerned about risk and data governance, the growth of DevOps has been potentially concerning. Without good communication here, there may be issues in new software packages or in new applications that represent serious risks. These issues can’t be allowed to get into production, yet security also can’t risk being seen as a blocker to all this new activity.

This has led to the development of DevSecOps, where security teams get embedded into the communication and software development processes earlier. This focus on both software and communication is important, as these activities have to go hand in hand with each other.

By getting security teams involved in the processes around software development – and more importantly by discussing the requirements around new applications earlier – the resulting software projects can be built with security in mind from the start.

This collaboration process involves understanding the mix of business goals, software requirements, and risk. For companies with clear reporting and communications, getting this information across and letting the software team develop results in faster software releases.

At the same time, it should also result in less risk to the business as well as security requirements are factored into the software development process earlier and any issues are fixed well in advance of them getting to production.

For security teams, being involved in shaping the communications processes between Dev, Ops, and Sec should be an essential step. According to research by Veracode, DevSecOps teams can improve the speed of mending application flaws as well, achieving fixes 11.5 times faster than traditional teams.

Building better processes using data

At the heart of all this work should be the data that applications create. Collating all this information and feeding it to the people involved in different roles across the business will support communication within teams, and between departments. Without this data, it is all too easy for existing communications approaches to affect development or lead to poor collaboration between teams; with more information available to software teams and IT security professionals, each team can focus on its own role within the wider process.

For DevSecOps, the role of machine data is to provide insight into what is taking place across an application’s components – the Dev team can see how the components themselves are put together, while the Operations team can see performance levels and where issues exist. For Security, any issues around data leakage or loss can be flagged for follow-up and for fixes to be applied. This data is coming in continuously, so you have to work with it continuously too.

However, this data can have a more profound effect on the business as a whole. With so much of the average company’s operations depending on IT and applications to work, the data on this infrastructure provides more direct insight into how any decisions made affect results. Communicating this data – and doing so both effectively and pervasively – should therefore help business users make better decisions and thus influence the future of the company. 

Over time, the value of this continuous intelligence data being shared may start to change how the company operates – rather than sticking to existing models, it should encourage different ways of approaching decisions. Rather than the communications approach affecting the design of systems, as Conway’s Law states, the reverse may start to become true, where any approach to sharing data internally within the company will begin to affect the design and model of the company as a whole. 

For DevSecOps, the challenge here is to keep these communications clear and effective as well as secure. Machine data will be essential in making this process work, as well as fueling the business itself.