Establishing Governance for Internal Software Supply Chains

Over the past few months I've discussed in my blogs how to better work with the open-source community and third-party software suppliers. (See: How to Work Better With the Open-Source Community.) Continuing our discussion on the different forms of the software supply chain, this month we look at the best practices for software governance for internal software supply chains.

An internal software supply chain results when multiple teams work together on components of a system and there is a handoff or integration of these components before they can be assembled into a functioning product. Often, internal teams are siloed organizationally, and visibility can be poor across teams. Having teams in different geographies can further complicate things by introducing time zones, complex scheduling, poor communication, and cultural barriers.

One way to combat these issues is to define a framework for common objective standards for software quality and security, and to integrate software and test it regularly to ensure it meets these standards. Here are some of the areas that can be managed:

  1. Software quality:
  2. Modern static analysis solutions provide a cost-effective and automated way to provide a metric for software quality. By setting a policy that defines classes of critical defects and the allowable defect density, different components can be measured objectively against each other and problem areas can be identified early. By increasing the visibility of software quality on a continuous basis, teams are motivated to do their best to keep up with their peers.

  3. Technical debt:
  4. Code that works functionally might still be built in a poor way that makes it hard to maintain. The notion of technical debt captures the idea that a byproduct of developing some code might be a debt that needs to be paid off later in order to add new features in the future. If a project accumulates a lot of technical debt over time, the speed of development will gradually slow down more and more until adding new features is very expensive.

    Traditional testing is not sufficient to get a handle on technical debt because it affects the malleability and cost of software in the future, not the features that work today. To get a handle on technical debt there are multiple metrics, including cyclomatic complexity and code comment density, which can help catch code that fails to meet basic best practices.

  5. Software security:
  6. Security risks are ultimately caused by software flaws. By ensuring that poor practices are avoided, many security vulnerabilities can be eliminated during development before they become an issue that a security auditing team must deal with, or worse, cause a security vulnerability in deployment.

There are common threads through all of these areas that form the core of software governance. These are:

  • Defining policies based on actionable metrics.
  • Testing code to determine compliance with these policies.
  • Managing teams to ensure violations are addressed and additional actions are taken to bring teams back into compliance.

This basic process is similar to the high-level governance practices followed by other parts of organizations, such as finance and legal, but they are largely foreign concepts in the world of software development. That will someday change. What do you think?

5 comments on “Establishing Governance for Internal Software Supply Chains

  1. DataCrunch
    May 25, 2011

    Hi Andy, thanks for the post.  All the points you mentioned are important.  I also believe that there are a lot more collaboration tools and platforms available today than years ago, which makes the software supply chain function more cohesively in team environments.   

  2. itguyphil
    May 25, 2011


    This is true. THe only barrier afterwards is to get everyone on board to use it efficiently. That's the majo roadblock I've come across.

  3. jbond
    May 26, 2011

    This sounds like an excellent set up. This is designed almost like checks and balances set up. Would work great if you can get everybody to cooperate and work in a timely matter. I am curious as to why more companies haven't adopted a plan like this a long time ago? It would seem like if this was in place, many companies could have avoided cost over runs and major delays in implementation.

  4. Hardcore
    May 27, 2011

    Hi Andy,

    The points you make are certainly form a good basis for software development, one other major area is code integrity, this is also an issue that has come to a head in a number of other open source  developments.

    By integrity I mean  code purity, copyright and indemnity against copyright, this is the current basis of the lawsuit between Oracle and Google, Oracle claims that Google misappropriated section of code belonging to Oracle(sun).

    It has also been an issue in some parts of Linux, where code was utilized but was not free from copyright of a third party. 

    Such control is far harder to control than the other points you listed, mainly because the  points outlined by youself , tend to fit nicely within a framework that can be  audited.

    For example in China it is very common for people working on a code base to take it with them when they move to another company, and indeed such code is freely available on the market.

    One of the hardest tasks for a software development manager is to secure the computing equipment used by programmers whilst they are developing software, even  cutting external network access is no longer a guarantee that a companies intellectual property will find is way out of a companies software development area and into the public domain.




  5. Taimoor Zubar
    May 30, 2011

    I think code integration is one of the most difficult aspect of software development and one of the major reasons why a lot of software projects fail is because of poor integration, despite the fact that individual components may be of high quality.

    From what I have seen, a lot of code integration problems arise because, as you said, there is a lack of predefined framework and agreed upon methodologies. In cases where software components will be distributed across multiple teams, the foremost requirement is to establish a common platform and standard and communicate it effectively amongst the teams. Also, any updates on the framework should be rolled out to the teams.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.