Designing an Agile Software Portfolio Architecture: The Impact of Coupling on Performance

Abstract

The modern industrial corporation encompasses a myriad of different software applications, each of which must work in concert to deliver functionality to end-users. However, the increasingly complex and dynamic nature of competition in today’s product-markets dictates that this software portfolio be continually evolved and adapted, in order to meet new business challenges. This ability – to rapidly update, improve, remove, replace, and reimagine the software applications that underpin a firm’s competitive position – is at the heart of what has been called IT agility. Unfortunately, little work has examined the antecedents of IT agility, with respect to the choices a firm makes when designing its “Software Portfolio Architecture.”
We address this gap in the literature by exploring the relationship between software portfolio architecture and IT agility at the level of the individual applications in the architecture. In particular, we draw from modular systems theory to develop and test a series of hypotheses about how different types of coupling impact three specific dimensions of agility: the ability to update, remove and replace software applications in the firm’s portfolio. We test our hypotheses with data from a financial services firm, encompassing over 1,000 software applications and 3,000 dependencies between them. We capture data at two points in time, allowing us to identify changes in the software portfolio, and hence to develop robust measures of IT agility.

Set in March 2018, the case follows ride-sharing company Uber as it develops and launches a new product called Express POOL. This product offers a reduced price to riders willing to carpool, walk a short distance to/from their pick-up and drop-off points, and wait a few minutes before being matched to a driver. Two weeks after the launch of Express POOL in six U.S. cities, Uber’s product managers discover that if riders are made to wait five minutes to be matched to a driver—rather than the standard two minutes—rider cancellation rates increase, but Uber’s costs per ride are reduced. Together with data scientists, engineers, and product operations specialists, the product managers must decide whether to keep rider wait times at two minutes or increase wait times to five minutes in the six newly launched cities. The decision is complicated by the fact that Uber’s data science team normally places a five-week moratorium on changes to any new product, to allow robust data to be collected on its performance.
This case is paired with a supplementary dataset from Uber (courseware no. 619-702). In advance of the class discussion, students can analyze the data and draw their own conclusions about the trade-offs of maintaining the standard wait times or increasing them.