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:
Software quality:
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.
Technical debt:
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.
Software security:
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?
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.
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.
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.
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.
EBN Dialogue enables and encourages you to participate in live chats with notable leaders and luminaries. Not only editors and journalists, but the entire EBN community is able to comment and ask questions. Listed below are upcoming and archived chats.
Archived Dialogues
Thailand Stages a Comeback Join EBN contributor Jennifer Baljko on Thursday August 23, 2012, at 11:00 a.m. EST for a live chat on how electronic manufacturers in Thailand have shored up their supply chain to reduce the impact of future natural disasters.
Euro-Crisis: What It Means for High-Tech Firms Join EBN Editor in Chief Bolaji Ojo and Contributing Editor Jennifer Baljko on Thursday, July 12, at 10:00 a.m. EDT for a Live Chat on high-tech and Europe's economic difficulties.
Microsoft Surface: Potential Winners & Losers What are the implications for the electronics industry supply chain of Microsoft Corp.'s decision to launch its own tablet PC? Join industry veteran and EE Times' systems and OEM expert Rick Merritt on Tuesday, July 3, at 12:00 pm EDT for a Live Chat on this subject.
Join EBN contributor Jennifer Baljko on Thursday August 23, 2012, at 11:00 a.m. EST for a live chat on how electronic manufacturers in Thailand have shored up their supply chain to reduce the impact of future natural disasters.
Peter Drucker famously said "Trying to predict the future is like trying to drive down a country road at night with no lights while looking out the back window." Yet in the razor's-edge world of electronics—with a lean supply chain and just-in-time demands—the need to know the future is vital.
While no one really can accurately predict the future, we can take guidance from another Drucker saying which is the best way to predict the future is to create it.
You've heard the saying "the No. 1 supply chain risk is your people." That hasn't always been the case. But today's complex global supply chain requires a new type of multitalented employee. It's one who understands, finance, marketing, economics, is savvy with technology, graceful with relationships and can think analytically.
Where are these people? Are universities properly preparing the next generation supply chain professionals? How do train your existing workforce for these new, demanding positions?
Brian Fuller, editor-in-chief of EBN, will lead a 60-minute Avnet Velocity panel discussion that will ask and answer these and other questions swirling around today's supply-chain talent challenges.
To save this item to your list of favorite EBN content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This