Previous column

Next column

---

The Weak Link in the Supply Chain John D. McGregor, Clemson University and Luminary Software, U.S.A.

COLUMN PDF Version

Abstract

Component-based software techniques have promoted a market of components that can be puchased and integrated to produce a product. Companies that produce software-intensive products using purchased software are experiencing the uncertainty and frustration that comes from including software development companies in their supply chain. In this issue of Strategic Software Engineering I will discuss how companies are addressing these issues and what more can be done.

1 INTRODUCTION

As the newly appointed vice president for manufacturing for a major automotive manufacturer, you are surprised to learn that over one-third of the cost of your luxury models comes from software and electronics and that the next generation of luxury cars for which you are planning now will likely host 1 gigabyte of binary code [Salzmann 04]. You are dismayed to learn that half of all software development projects are delivered late, over budget, or with reduced functionality[Standish 94]. After all, automotive suppliers must achieve a 98 – 99% on-time, to-standard delivery record [Gould 04] to be considered good. You now see your goal of reducing order-to-delivery time of a luxury car as nearly impossible. A mechanical engineer by education and experience you feel unprepared to meet these challenges.

The reliability of a company’s supply chain is a fundamental ingredient in accomplishing the company’s strategic objectives. As the software content of most hard goods products increases, the potential for impact on the company’s supply chain by software development also increases. An increasing number of companies count on software development efforts to be on-time, within budget, and to standard as an integral part of a larger product development effort.

Lets be clear about what I mean by “supply chain.” When you produce any product, the resources needed to create that product are obtained in a variety of ways. Automotive manufacturers rely on producers of tires, seats, axles, and much more to supply some of the basic parts of each car and some they build themselves. The auto manufacturer’s ability to create a car depends on all of those suppliers doing their jobs. In turn, the suppliers’ ability also depends upon their suppliers.

Supply chain management (SCM) extends from a company’s suppliers, both direct and indirect, to its customers. Supply chain management seeks to reduce time to market, reduce costs, and maximize sales by managing the flow of “stuff” and information about the stuff. This includes alerting customers to changing delivery dates. Managing a customer’s expectations is much easier a few months before a scheduled delivery that won’t happen than it is a week before. For an industry that invented the term vaporware this is tough to do but essential to maintaining business-to-business relationships.

The supply chain extends back to the company’s suppliers, and to their suppliers. A failure anywhere along this chain threatens timely deliveries forward in the chain. Supply chain management seeks to reduce the probability that problems will occur and the cost that will be incurred if they do occur. SCM requires collaboration among the sets of suppliers.

The software development community has made progress toward on time, on standard deliveries, but we still have much to do. That’s what I would like to discuss in this issue, but I will stay away from the purely business issues and focus on technical activities related to strong supply chains. First I will describe our manufacturing process and how it interacts in a supply chain. Then I will discuss what we and our customers are doing from a supply chain perspective.

2 OUR MANUFACTURING PROCESS

Software is different. That is what we like to say and hope that it explains why we can’t produce quality products in a timely manner. It doesn’t. The cell phone manufacturer who misses their market because the software browser was delivered late by a vendor isn’t interested in excuses, just damages.

Software IS different, but that just means we have different problems and need solutions that are different from those in hard goods manufacturing. The manufacture of the physical embodiment of our products, our deployment media, is seldom a problem. Our problems come in what would be the equivalent of the design process of hard goods. Our manufacturing process is essentially the software development process.

One problem is that software is too soft. There are no immutable laws of physics that constrain our design. Designers are faced with a mind boggling array of choices. Projects often are late because of all the design possibilities, the difficulty in selecting among them, and the irresitible urge to continue to tinker.
On the other hand, as a software product grows in size, the software becomes hard quickly. Technologies such as component-based development are intended to prevent pre-mature harding of the software product. Components provide pieces of software that are, hopefully, just the right firmness. They are the right size to have a complete specification and have the right structure to be able to adapt, via different implementations, to changing non-functional requirements. Their size is a tradeoff between firmness and economic feasibility.

Our manufacturing process has a supply chain. In fact some software product companies do nothing but buy component parts and integrate them. Others buy some portion of their product and build the rest. We all buy tools. Poor quality or late delivery of some of these products is easily handled but others can be devastating. The failure of a vendor to release the completed new version of a library is manageable unless the new version fixes a serious bug or provides a new feature that we relied on in designing our next product. Failure in a supply chain is magnified as the delivery date slips in one company after another up the chain.

Our supply chain is not limited to other software companies. Admittedly, the failure of a hardware vendor to deliver a standard workstation can be quickly remedied by going to a different vendor but the failure of a vendor to delivery a new high performance server to the testing team can mean unavoidable testing and deployment delays. Services such as consulting and training must also be delivered on time to have the appropriate impact on development effort.

The current movement toward outsourcing can have significant impact on our supply chain. Automotive manufacturers usually require suppliers to have facilities close at hand so that deliveries are quick and reliable. It would seem to be different in our information world where software can arrive instantly from anywhere in the world; however, can we rely on a supply chain that goes around the world and relies on bi-directional flows of understanding among humans? It depends on our tools and processes.

Software is in the supply chain of a large percentage of products in the marketplace, including our own. Let's consider some of the same techniques that hard good manufacturers use to ensure supply chain integrity and then we will see how these apply to us.

3 WHAT ARE THE AUTOMOTIVE SUPPLIERS DOING?

As I have already said, automotive suppliers achieve high levels of delivery quality so let’s consider four of their practices [Vasilash 04].

• Automate SCM – Manufacturers automate as much of the supply chain management process as possible.
• Use best practices – Manufacturers focus on improving their manufacturing processes by incorporating best practices.
• Integrate suppliers and customers – Manufacturers strive for collaboration up and down the supply chain to improve the acceptability of products being pushed up the supply chain.
• Establish visibility to mitigate risk – Manufacturers seek to mitigate risk by gaining more visibility into suppliers’ ever changing capabilities and customers’ ever changing needs.

They are not perfect. They still use a push model, where products are pushed through the supply chain to customers, particularly between auto manufacturers and auto purchasers. The manufacturers are looking toward being able to implement a pull model where a customer can custom order and receive their product in a reasonable amount of time, which is seldom the case now.

Our supply chain is similar to those in any industry. Our problems are similar and our actions are similar so I will not address the activity of automating SCM in this column. I will describe how we are, or should be, doing the other three practices.

4 WHAT ARE WE DOING?

Software development has changed, for most of us, since vaporware stole our credibility. A number of factors are coming together to make our manufacturing processes more predictable and our role in a supply change more reliable.

Process Definition and Improvement

Can you imagine each chemist at Michelin making tires differently? Or worse, every chemist making every batch of tires differently every time? Much attention has been focused on repeatable and manageable software development processes and much effort has been expended to mature our profession in this area. The Capability Maturity Model (CMM®¹) and Capability Maturity Model-Integrated (CMMI®¹) products of the Software Engineering Institute (SEI) are giving companies a step-by-step guide to improving their process definitions [SEI 04a]. The Software Engineering Body of Knowledge (SWEBOK) gives companies guidance on the content of those areas described in CMM documents[SWEBOK 04].

Organizations that use techniques that improve quality, such as inspections, actually are the most productive as well. This is because they waste less time searching for defects than those companies that don’t address quality until late in the process. Efforts such as the Personal Software Process (PSP®¹), and Team Software Process (TSP®¹) initiatives at the SEI are providing avenues for software manufacturers to improve their quality and productivity[SEI 04b]. Microsoft and the SEI recently announced the results of a study in which developers reduced their defect rate from 25 defects/KLOC to 7defects/KLOC [Kimberland 04]. They experienced a 35% cost savings on the project due to a reduced need to fix defects.

These results and others show the falacy of the old approach: “There is never enough time to do it right but always enough time to do it over.”

Reuse

Many reuse schemes have been tried and most have failed to deliver strategic value. Why do we keep trying? Software has more predictable quality and can be manufacturered in a more predictable time box by using pre-existing parts if those parts are appropriately designed and implemented.

What has been wrong with many of the reuse approaches? Vague requirements. Assignments such as “Build this component to be as flexible as possible” are not sufficiently constrained to allow for intelligent engineering. The engineer decides on one dimension of flexibility when the next project may really need a different type of flexibility.

Design for reuse in context is necessary. This can be accomplished in several ways. One way is standardization. Standard architectures, industry consortium standards, and government standards provide the opportunity for multiple vendors to form a competitive market place. An example are the web browers that run on wireless platforms using the wireless access protocol (WAP), which can now be purchased from multiple vendors.

My favorite technique for achieving reuse in context, as should be obvious from previous columns, is a software product line where elements are used with a minimum of modification [Clements 01] on several products. The assets in a product line are only intended to be used within the constraints of the products defined in the product line. The financial viability of building the components to be reusable across the fixed number of products in the product line is evaluated as part of developing the business case. The viability is established before resources are expended on developing the components.

A third way to achieve high quality reuse in context is through a comprehensive library or framework built around an architecture. The Eclipse project is not a product line but it is intended to be the basis for a large number of products of a specific kind. It is a set of projects developing comprehensive libraries of classes that work around a specific architecture for a reasonably specific purpose. In this case, elements are more often extended before being used than used as is, but those extensions are anticipated and compositional.

In each case, there is a learning curve. Using Eclipse as the basis for only one product is not a cost effective approach. The amount of effort to understand the nuiances of the dependencies between classes in the library is considerable and must be amortized over several products.

Risk Management

Risk assessment and mitigation are project management best practices. Many management processes now include risk-based techniques for using risk to adjust for the sensitivity of their estimates to uncertainty. The two attributes of any risk are the probability that the event will occur and the cost if it does occur. Risk assessment depends on collecting data from which the probabilities can be computed. Mitigation works to either reduce the probability of occurrence or the cost of occurrence.

The probability of an anticipated risk event occurring can be reduced by the use of software engineering “best practices.” For example, an unambiguous, complete requirements model reduces the likelihood of missing functionality in the product. In the next section I will discuss “due diligence” in which the customer seeks to determine the probabilities of risk events, in which they have an interest, occurring in our work.

The cost to the customer of a risk event occurring can be reduced by close collaboration between supplier and customer. Many successful supplier relationships operate on two levels to maintain visibility into each other’s processes. The business relationship is maintained by management to ensure compliance with the contract and any applicable laws and regulations. A technical relationship is also established in which a technical contact makes periodic reviews of progress at the supplying company. The technical connection will identify risks to timely, quality deliveries while the financial connection may identify budget busting situations if the contract allows for increased costs to be passed on to the customer.

Quality Assurance

A number of activities are grouped under the heading of quality assurance, sometimes but not always including testing. Over time the focus of QA efforts has moved from system testing after the development is completed to points much earlier in the development process. Activities such as training in new techniques, active inspections, and the adoption of tools that provide checking of their output are all quality assurance activities that reduce faults and increase our on-time delivery.

Quality assurance has two impacts on the supply chain. First, the presence of a well-defined QA program can give customers visibility into the company’s efforts to produce to-standard products. Reviews of the results of inspections and audits of training records can substantiate claims of quality development. Second, the QA program can improve the on-time delivery for the company by reducing the faults that cause product defects. Time is saved since there are fewer defects to chase down. With a comprehensive QA program, problems are known earlier and are more easily handled at the root cause.

5 WHAT ARE OUR CUSTOMERS DOING?

Our customers evaluate our role in their supply chain based on three attributes [SCC 03]:

• Reliability – How often do we achieve full delivery on-time, to-standard?
• Responsiveness – How quickly can we deliver a product once it is commissioned?
• Flexibility – How well do we respond to changes in the marketplace or domain?

They perform due diligence in selecting their vendors and practice risk management concerning the vendor’s role in their supply chain.

Due Diligence

Companies are becoming aware of the need to investigate suppliers before including them in the supply chain. Few of us would hire a contractor to remodel our kitchen without asking for references and checking on the contractor’s prior job performance. But I have consulted on at least one legal action where the CEOs of two companies were golfing buddies and a supplier relationship was entered into with no due diligence.

Even though the quantitative management of projects is not required until Level 4 in the CMM, companies that expect to supply software-intensive products to other companies should not wait until they are moving to level 4 to systematically collect data. Industry data indicates that projects are slowly becoming more reliable; however, as stated above, half of all software development projects are delivered late, over budget, or with reduced functionality. If you are significantly better than that average you need to be able to prove it.

From a supply change management perspective, due diligence seeks to determine the quality of a company’s on-time, to-standard record. But we would like to go beyond these basics. What is the average time to respond to a requirements change? What is the turn over rate in domain experienced personnel? Do they have a plan for maintaining currency of knowledge in their personnel?

The information collected during due dilligence is input to the contract negogiation process. We may not reject a vendor because of what is found during due diligence, but we may adjust what we are willing to pay. Assume more risk, pay less.

Risk Management

Our customers are as concerned about minimizing risk as we are, maybe more. They evaluate our reliability for future use. Our failures to deliver will come back to haunt us in future marketing when customers press for reduced prices to compensate for increased risk.

Our customers, the savy ones anyway, are requiring an open process where they can monitor and evaluate the quality and timeliness of our work. This often means that valuable engineer time will be required to participate in joint requirements, architecture, and design reviews. The good news is that if we are proactive we can use these reviews to our advantage. Select the areas in which your staff has questions and suggest to the customer that those areas be reviewed. Use the review time to get your questions answered. Drive discussions deep into areas where you feel you have good ideas.

6 WHAT ELSE SHOULD WE BE DOING?

Benchmarking

How are we doing compared to other vendors in our market in terms of on time, on standard delivery? I had an operation a few years ago that was reasonably serious. In talking with a surgeon that I might have perform the surgery, the surgeon listed the possible complications, the average number of times each complications occurred for the general population of surgeons, and then his average for each complication. This was very useful information to have in choosing my “vendor.”

In our business the data can be difficult to collect cleanly. We allow changes in the requirements for a product later into the development process than almost any other industry. How should these changes reasonably be treated in terms of what delay does the change impose? Many companies provide “pre-releases” to customers. When do we really deliver and when is it really complete?

The expanding market for components provides a simplifying assumption. When we make a purchase we get almost immediate delivery. This makes “when” easier to identify.

Data-based decision making

Quantifying attributes of product development within a market, collecting data upon which to base decisions, is the single most important missing ingredient in our discipline. But equally important is the cultural view that such numbers must be suspect. Actual data shows that implementing techniques such as inspections during development has the highest return on investment of any process improvement investment [Jones 94] yet not every organization does inspections. Too often managers make decisions based on their personal biases and their belief that the latest silver bullet will save them. Use pilot projects, which may be real projects that are trying one specific new technique, to collect data and establish the viability, or lack there of, for the technique.

Process improvement, actually process modification, should be based on experience data rather than random decisions. I once wrote a column for the Journal of Object-Oriented Programming titled “Let’s Don’t and Say We Did. [McGregor 98]” The premise was that a manager sees a new buzz word, say pair programming, and wants to be seen as a cutting edge individual. So the manager says, “yes we are doing pair programming but it is too wasteful to have two developers at one computer. We only need one!” When the benefits of pair programming are not realized, the manager says “well these new ideas never seem to work.” Using small pilot projects to explore a new technique reduces the risk of the new technique but may still provide sufficient data for a manager to see the validity of the new technique.

Comprehensive production planning

Few companies create a comprehensive production plan for their software products. Planning one project at a time does not achieve any economies of scale or scope. By default, personnel develop expertise in the tools of their trade. Choosing a new language for every product or changing tools often imposes a learning overhead that is hard to compensate for.

Software product line development includes a production planning practice that ties the goals of the organization to the techniques used to build products [Chastek 02]. This goes to my basic view of engineering, “Building to a purpose.” Production planning relates each low level construction step back to the more general goals of the organization.

New development technologies

The improved support in programming languages and modeling languages for interfaces has improved the reusefulness of software. Component-based software design also holds much promise but there is still no widely accepted component-based language. Having a CLASS named COMPONENT is not the same as having COMPONENT as a first-class element in the language. Koala holds some promise but it is not widely used [van Ommering 00].

Better requirements

We should be giving our suppliers better requirements. Over half of defects are the result of misunderstood, vague, or incorrect requirements. Two simple things to do:

• Test the requirements. We often work with groups of domain experts to develop requirements. Our standard practice is to hold one or two of the experts out of the development group. The reserved experts conduct a “Guided Inspection” of the requirements developed by the larger group [McGregor 99].
• Use a sufficiently rich representation of the requirements. Lists in an Excel spreadsheet are a sign of too little detail and not enough information being communicated. Use cases, with some supporting text, provide the ability to write detailed requirements[Armour 00] and to show dependencies among the requirements. This is a must in an outsourcing situation.

7 SUMMARY

Many of us work in situations where our product is sold to be a part of a bigger product and often we are purchasing parts from others for use in our products. I have talked about several practices that are contributing to a more reliable industry and also pointed out some additional practices that need to be used more than they are now. I hope that this discussion will stimulate thinking about your role in the bigger picture of strategic supplier-consumer relationships.

Footnote

¹ ® CMM, CMMI, PSP, TSP are registered marks of the SEI.

REFERENCES

[Armour 00] Frank Armour and Granville Miller. Advanced Use Case Modeling: Software Systems, Addison-Wesley, 2000.

[Chastek 02] Gary Chastek and John D. McGregor. “Guidelines for Developing a Product Line Production Plan”, CMU/SEI-2002-TR-006.

[Clements01] Paul Clements and Linda Northrop: Software Product Lines: Practices and Patterns, Addison-Wesley, 2001.

[Gould 04] Larry Gould. Automotive Supply Chain Management: As Good As It Gets? http://www.autofieldguide.com/articles/020306.html.

[Jones 94] Capers Jones. Assessment and Control of Software Risks, Englewood Cliffs, NJ: Youdon Press, 1994.

[Kimberland 04] Kelly Kimberland. “Microsoft’s Pilot of TSP Yields Dramatic Results, ” news@sei, 2004(2).

[McGregor 99] John D. McGregor. “Validating Domain Models”, Journal of Object-oriented Programming, July/August 1999.

[McGregor 98] John D. McGregor. “Let’s Don’t and Say We Did”, Journal of Object-oriented Programming, September 1998.

[Salzmann 04] Christian Salzmann, Thomas Stauner, and Alexander Pretschner. ICSE Workshop: Software Engineering for Automotive Systems.

[SEI 04a] Software Engineering Institute. The Team Software Process (TSP) and the Personal Software Process (PSP), http://www.sei.cmu.edu/tsp/.

[SEI 04b] Software Engineering Institute. Capability Maturity Model Integration, http://www.sei.cmu.edu/cmmi/.

[Standish 94] The Standish Group. Charting the Seas of Information Technology, Dennis, MA: Standish Group, 1994.

[SCC 03] Supply Chain Council. Supply Chain Operations Reference Model (SCOR), 2003.

[SWEBOK 04] Software Engineering Coordinating Committee. Guide to the Software Engineering Body of Knowledge, http://www.swebok.org.

[van Ommering 00] Rob van Ommering, Frank van der Linden, Jeff Kramer, and Jeff Magee. ”The Koala Component Model for Consumer Electronics Software”, Computer, IEEE Computer Society, March 2000.

[Vasilash 04] Gary S. Vasilash. Leveraging the Supply Chain for Competitive Advantage, http://www.autofieldguide.com/articles/040206.html.

About the author

Dr. John D. McGregor is an associate professor of computer science at Clemson University and a partner in Luminary Software, a software engineering consulting firm. His research interests are software product lines and component-base software engineering. His latest book is A Practical Guide to Testing Object-Oriented Software (Addison-Wesley 2001). Contact him at johnmc@lumsoft.com.

Cite this column as follows: John D. McGregor: “The Weak Link in the Supply Chain”, in Journal of Object Technology, vol. 3, no. 8, September-October 2004, pp. 71-80. http://www.jot.fm/issues/issue_2004_09/column7