Friday, November 21, 2003

Influencing Batches of Triangles

I’m begining to see “Agile Management…” and its promotion of the Theory of Constraints in software development have an influence on other authors. In this Technical Report from October, Alistair Cockburn, cites my book as an influence when he examines whether “process” is the fourth constraint and whether use of appropriate process can be used to “trick” what he calls “the iron triangle” of the three primary constraints in software development - schedule, scope and resources. This is the first citation I’ve noticed for the book. Thanks, Alistair!

Also, in their latest newsletter, Mac Felsing and Jeff Cohen, of ProcessExchange, explain why small batch sizes are better in software.

Thursday, November 20, 2003

The myth of the Cost per Megabyte

In Chapter 17 of “Agile Management…”, I take a serious look at product management for software services and examine the business model - I choose to use the telecom industry as an example. In order to explain how to do product mix selection, I first have to recast the standard telecom financial model of EBITDA=ARPU-CCPU (Earnings before interest, tax, depreciation and amortization equals average revenue per subscriber less cash cost per user (times the number of subscribers)), into a proper Throughput Accounting model. This was non-trivial.

As many people who read this column know, I work in the wireless data services industry. It is no secret that I used to work for one of the big US carriers, often considered one of the smarter and more innovative - Sprint PCS. When deploying wireless data services, any marketing manager at a carrier is required to construct a business model for the service - remember the service is basically just software in operation. Hence, the business model relates directly to the features that must be coded in the software. Many managers are trained to think in cost accounting terms and work their plans around the “cost per megabyte” and the “revenue per megabyte”. The supposition is, that if revenue exceeds cost then you build the software and deploy the service. What’s wrong with this model? Simply put it - there is no such thing as a “cost per megabyte” and framing a business case in these terms is simply trying to measure the wrong things.

It is way past time that wireless phone companies realized that there business is more like selling seats on aircraft than commoditized physical components as this article [E+ membership required] in the Economist explains. The essence of the problem is that the cost of building the wireless data network is a sunk cost. There is virtually no marginal cost to carrying megabytes of data across the network. Hence, the true “cost per megabyte” is really $0.00 - nothing!

When might this not be true? In 2.5G networks, the data and voice carrying capacity exist in the same channel space though voice is essentially traditional circuit switched technology whilst data is packet switched. Networks are configured to transfer capacity between voice and data depending on demand. Usually voice takes precedence since it was assumed that voice was (a) more important for customer service and expectations, and (b) more valuable - this assumption may prove to be wrong but that is another story. Hence, the total capacity or bandwidth of the network is a constraint - ah ha! So we have the system constraint. In the event that the capacity is full, then and only then, is there a potential cost of carrying an extra megabyte. That cost is essentially the opportunity cost of carrying some other traffic which might generate more revenue. Until the capacity is completely allocated - there is no cost per megabyte. The cost is already sunk from the build out of the network and is being amortized as a fixed cost rather than a marginal cost per megabyte transported. When the constraint is reached, the ideal carrying mix would be determined by the highest revenue per megabyte.

In Good to Great, Jim Collins explains that great businesses figure out what drives their economic model and what determines the correct denominator with which to measure performance. He gives an example of Walgreens which chose to measure “profit per customer visit” rather than “profit per store”. The latter would have driven behavior which encouraged them to close small stores and open fewer larger ones, serving larger areas. This would not have made them great. They became great by opening more stores in convenient locations and generating more customer visits as a result. In turn those greater number of visits generated more profits because store managers were asked to focus on how to make the most “profit per customer visit”. The choice of denominator which made Walgreens great was “customer visit”.

Coming back to wireless data telecoms, “megabyte” is the wrong denominator. What would be a better denominator? “Subscriber month”, or possibly even better is “subscriber communication”. In this latter model, the wireless data services product manager is focused on generating the most number of unique communication events. However, “cost” is the wrong numerator. The numerator must be “revenue”. In Throughput Accounting, revenue is most important factor, investment is of second most importance and cost a distant third. I explained this in Chapter 2 of “Agile Management…”.

Why is all of this relevant to software engineering management? Well, the business model for the service, determines whether the software is commissioned or not. Further to this, it affects engineering decisions and architecture as well as features. If the mind set of marketing is set by “cost per megabyte” rather than “revenue per subscriber communication”, imagine the difference it makes to both functional and non-functional requirements in the release mix.

Requirements start with product concepts and product concepts are enabled by market opportunities and a realistic go-to-market strategy (or business model). With the wrong business model, the wrong software gets written, the consumer is disappointed and profits are left on the table when they might otherwise have been turned into shareholder value. The most agile thing any software engineering manager can do, is refuse to build what the customer doesn’t need. In order to do that, the product or service definition must have been couched in the correct business terms.

Extreme Transparency

Those who have read some of the book will know it is about transparency of process and transparency of tracking the flow of value through the software engineering lifecycle. I really liked this example [E+ membership required] of “extreme” transparency from Japan’s recent general election as described in The Economist print edition November 15th page 25. Here is the relevant quote…

Mr Kan told voters that the flamboyant governor of Nagano - who works in a glass office so that everyone can see whom he meets - would join the DPJ cabinet if the party won the election.

Tuesday, November 18, 2003

Centralized Process Selection Decisions

It is now widely recognized that with software development processes - one size does not fit all! This goes as much for eXtreme Programming as it does for SDLC or RUP. In The Right Tool for the Job, Scott Ambler examines the issues in the latest issue of Software Development magazine. Scott references using risk assessment as a tool to help select the right process and points the reader at the recent Boehm and Turner book, Balancing Agility and Discipline.

Last week, I talked about the problems of having a centralized group which selects tools for use in software development. The same applies to software process. It makes no sense to have a centralized proclamation that the entire enterprise - and I’ve worked in companies with 20,000 software developers - should use RUP (as an example). Software process choices should be aligned with value chains. The market into which the software is being deployed should be understood and an assessment made as to the stability of the requirements and the likelihood that the application can be deployed iteratively or incrementally rather than holistically. This is what Boehm and Turner call a risk assessment. There are other treatments of the problem.

In Chapter 34 of “Agile Management…” I divide the problem into a 2x2 matrix providing for 4 categories: immature holistic domains; mature holistic domains; immature incremental domains; and mature incremental domains. I then suggest process choices for each of these quadrants.

In Agile Software Development Ecosystems, Jim Highsmith maps the problem space using Geoffrey Moore’s technology adoption lifecycle model of Early Market, Chasm, Bowling Alley, Tornado and Main Street, as described in his books, Inside the Tornado and earlier in Crossing the Chasm.

So there is lots of advice out there. The bottom line is that this advice should be followed on an as needed basis - by project or business unit. There should be no grand centralized choice made in the ivory tower. The minor cost efficient advantage of having all the staff trained in the one method, is far outweighed by the problems created and the cost in real ROI terms by using the wrong tool for the job.

Monday, November 17, 2003

Supply Chain Software Development

I’ve mentioned the notion of creating a software development supply chain to assemble software from components before at this site and on my Yahoo! group. Now Clemens Szyperski and David Messerschmidt develop the idea and examine what makes it different in The Flexible Factory [registration required] in the December issue of Software Development magazine. They speculate that software assembly would be a new “industrial revolution”.

They also observe that a market must exist for components. This is not a new observation. The component world dream really started with products like the OS/2 Workplace Shell (OS/2 2.0). That dream was so far ahead of its time that technologies such as CORBA had to be invented for it. In an interview I conducted with Dave Roberts, one of the designers of the Workplace, he recognized the deficiencies of the model - no market place. However, the markets such as ComponentSource and Flashline do not really solve the problem. Any VC will tell you - “there is no money in (software) components”. Why not? There is huge money in PC components e.g. processors (Intel) and disk drive controllers (IBM). The reason is that value cannot be measured and hence value falls to the lowest common denominator. Value is primarily determined by cost. Not by the risk carried in the value chain. All that these companies are providing is an online version of wholesaling for component libraries. Something we used to do from firms such as Greymatter.

Dave Roberts believed that web services were the answer to the problem. Runtime metering of method calls. I believed this too and was responsible for an infrastructure called “Wireless Application Manager” which planned to offer runtime metering and billing for wireless web services on the Sprint PCS Vision network. That system was never implemented but ideas like it are beginning to emerge. For example, it is now possible, using technology similar to aspect-oriented programming to weave code into applications which meters the use of method calls and reports it to a central billing system - such as that owned by an ISP or a telco.

This solves the final problem identified by Szyperski and Messerschmidt - that of trust and risk. In the design for Wireless Application Manager, for example, all web services were non-repudiated end-to-end through X-509 certificates on the supplier end and through the handset identification on the other. The access carrier is best placed to play the role of trust mediator. They can also provide quality of service - something which wasn’t identified in the SD magazine article. By allowing price differentiation across quality of service lines, supply of services or components will naturally align with value chains and risk is spread across the suppliers in the chain.

The bottom line is that there is a whole lot of infrastructure to be built out before supply chain assembly of software applications will be possible. It involves the development of network access operators to facilitate the marketplace and provide the trust, quality of service, metering, billing, mediation and settlement. It requires a wider use of a meta-data language such as RDF but one which is capable of semantically describing an application in a way which can be identified in an agreed ontology along with its quality of service ranking and its terms and conditions of service, including price. For example, does a downstream partner get a discount for volume - and if so, how much, and how is this administered? Does the end user get to specify QoS and Trust levels for an application such that all the components or services it taps into fit that designated level and will the price the end user pays vary accordingly? Is there a concept of first class, business class and economy for use of a word processor?

Maybe! Just maybe… Check back in 15 years.