devopsy.kinsta.cloud

Tag: Conways law

  • Should Conway’s Law Be Applied to DevSecOps?

    Should Conway’s Law Be Applied to DevSecOps?

    Strictly adhering to Conway’s Law could lead to less innovation and the inability to keep up in a fast-changing market

    When it comes to determining how an organization should be structured, the 1967 Conway’s Law provides a plausible direction that many software companies could follow. However, in today’s ever-changing cloud environment, it is arguable whether it can be used in DevSecOps companies, a quickly growing organization structure. While Conway’s Law is helpful to consider, it should only be used as a guideline and not strictly followed because it can lead to less innovation and the inability to keep up with the fast-changing market.

    What is Conway’s Law?

    Conway’s Law is a term that originated from engineer Melvin Conway’s 1967 thesis paper to Harvard Business Review. In his submission, he wrote that “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 methods.” Based on his observations in the engineering world, he believed that the success of a software is based on the organization’s company structure and communication style. As a result of this paper, software companies began to emphasize collaboration and teamwork and implemented it into the company’s work culture.

    How Can Conway’s Law Apply to the DevSecOps Field?

    Conway’s Law has many valid points. The law emphasizes the importance of a company’s structure and the necessary balance of business and design to ensure a viable product, as the quality of a product “comes from within.” However, there is no right way to organize a company, and it should be structured in a way that makes the most sense for an evolving, cloud-based product.

    In the DevSecOps field, many solutions are run by enterprises that are cloud-based. This means that all the data and networks are stored in remote servers, making it easier for companies to constantly develop new technology and improve existing products. This new norm is redefining the way companies are structured today, and traditional standards cannot be followed. If a company strictly follows Conway’s Law, it will be difficult for them to innovate.

    Here are a couple of takeaways from Conway’s Law that can benefit DevSecOps companies:

    Small Teams With Equal Representation

    Conway’s Law explains that the bigger the team, the higher likelihood of miscommunication and tension, causing unproductivity. Many tech companies, such as Microsoft and Amazon, structure their employees in small teams (around 10-15 members) to oversee and specialize in a specific aspect in the company’s product, but aim to achieve the same business goal. This type of structure allows more leeway to experiment different ideas and quicker response time to fast-changing needs.

    Collaboration is Key

    Some argue that following Conway’s Law may decrease the company’s overall cooperation and lead to small team allegiance. While there is a fine line between small work groups and department cliques, collaboration needs to be a core concept embedded in the company’s organization.

    If the organization’s culture is based on companywide collaboration, it will solve these problems, as collaborative processes and platforms prevent cliques from forming and allow teams to be independent, creative and agile. For example, for security teams to successfully collaborate with DevOps teams, they need to intentionally create solutions that can be embedded with existing DevOps pipelines.

    Conclusion

    While Conway’s Law is an important social contribution to organization principles, it should only be used as a rough guideline because following it too closely can stymie innovation in a fast-changing cloud environment. Conway’s Law highlights the importance of company structure and implies that a successful organization is structured with small teams focusing on one sector of the company, and with consistent collaboration established throughout the company to systematize unification and togetherness.

    As organizations compete for the greatest slice of pie, it is critical for leaders to look inward and ensure internal structures and processes are setting their products up for success.

  • Conway’s Law

    Conway’s Law

  • The Holistic Nature of DevOps, Architecture and Methodology

    The Holistic Nature of DevOps, Architecture and Methodology

    Throwing it Over the FenceDevOps

    DevOps…It’s become a term that has devolved to describe too many of the wrong things. Job titles like “DevOps engineer” and “Director of DevOps” and even DevOps training and certification programs hide an important issue of what DevOps was originally meant to be…

    If you’ve ever read “The Phoenix Project“, “Release It” or “Continuous Delivery“, (and you should) you probably already know that DevOps was never intended to be a title nor a department. DevOps is an organizational pattern. It’s what you get when development teams stop “throwing code over the fence” into production and start working together with IT operations personnel as members of cross-functional teams.

    Cross-Functional Teams

    Many so-called cross-functional teams usually consist of developers and testers; and sometimes even a business analyst or product owner. This is not what cross-functional means. True cross-functional teams include members representing the full spectrum of disciplines required to bring software from idea to production. Such teams include product owners, functional analysts, UX designers, developers, QA, DBAs, enterprise architects and IT Ops personnel, and these teams have full responsibility over all aspects of their software product until it is no longer in service.

    For many organizations, this is a bold departure from tradition in which development teams hand off completed software to a separate operations team for deployment and maintenance in production. The philosophy driving the DevOps movement seeks to eliminate this separation. But why?

    Handoffs are Wasteful

    Anytime the responsibility for a software product changes hands, even under the best of circumstances, some knowledge is inevitably lost. Additionally, each transfer of knowledge and responsibility along the production chain lengthens your product’s lead-time, incurring unnecessary costs. These costs might include time spent in meetings and writing detailed documentation instead of coding, plus delays in realizing revenue and ROI the longer your product takes to get to your customers.

    In Lean manufacturing and lean software development, any step in the process that moves unfinished product from one stage to another, making no changes to bring it closer to the state for which a customer would pay, is considered “waste of transport” – one of the original 7 forms of waste. One of the key goals of Lean is to reduce such waste, and one way to eliminate these handoffs is by having one team responsible for all aspects of the product. From the inception of ideas all the way into production—including bug fixes and production support—have one team communicating and working together all the way, making Conway’s Law work for you.

    Conway’s Law and Systems Architecture

    Over 40 years ago, programmer Mel Conway publicized his observation that the design of software systems reflect the communication structures of the organization that built it. This has since become known as Conway’s Law and recent studies have validated the idea.  The truth behind Conway’s Law is that, almost always, communication and activities in organizations follow the path of least resistance.

    For example, if the development team has to deal with too much red tape to get a database script into production, they’ll write a workaround in the application layer instead, which they control.

    This is also why most organizations in which development teams hand off code to ops teams wind up with code that is written well enough to pass acceptance tests in development and QA environments, but fail to take into consideration concerns like performance, security and scalability in a production environment. Teams that are structured to share information across departments and given autonomy to make decisions are better equipped to develop highly robust and cohesive systems.

    Not every team needs a dedicated architect, DBA, or Ops person. Depending on the needs of your organization, people in these roles can belong to multiple teams, providing much needed communication and consistency between their respective product teams and their departmental teams.
    In summary, organizing teams to be truly cross-functional, together with the application of Lean manufacturing principles, is how you can start to build a DevOps culture that will continue to deliver quality software for years to come.

    About the Author/Michael Ibarra

    Michael-Ibarra-devopsMichael Ibarra is a Solutions Consultant with AIM Consulting. A software craftsman, tech speaker and self-described troublemaker, he has been building software and development teams in the Seattle area for nearly 20 years.