The Revit Open Letter Through the Lens of QWERTY-Nomics

Continued from page 1

A Natural Monopoly—The Question

There is no question Autodesk has significant market share concentration in many markets of the global AEC industry. The Nordic Open Letter addresses this on the fringe in its opening paragraph, which reads:

“In February 2020, the European Construction Industry Federation (FIEC) released a position paper on the lack of competition in the software industry, with customers facing rising costs, [and] limited licensing options from a small number of competing developers.”

Natural monopolies tend to serve utility functions whereby duplicating costs to replicate identical systems does not yield any economic benefit to the end customer. In the early days of the telephone, it was common to see multiple physical phones on bank desks as each was connected to unique networks competing in a free and open market. The inefficiency was obvious—duplicate phones, lines, and interface hardware at the point of service on the street. Eventually, phone services and natural monopolies would sort their way out. Today customers have options and, most importantly, price pressure in the system. 

 

 

 

 

Data duplication in AEC is one area of waste and inefficiency but is solving that inefficiency through industry concentration correct and economically optimal? One way to evaluate that is to note that the development velocity changes when companies get too large or control too much of the market. We saw this with Microsoft and web browsers and operating systems decades ago. When companies get too large, leadership can only attend to so many items simultaneously, and intra-divisional coordination becomes more complex. And then, there is the public shareholder demand for growth. 

These items have likely conspired to form the conditions underlying the Revit Open Letter groups’ frustrations. The first Open Letter delivered the first prima fascia evidence of this fact. The company, in its apology, noted that the company’s AEC division attention was diverted away from the design side so it could accomplish and acquire construction sector software companies. It pointed out that the true potential of BIM could not be met if construction sector professionals were sitting outside Autodesk BIM solutions—a justification that carries some weight. 

A direct example of development velocity issues comes from BIG. Jens Kaarsholm told Architosh that they have been asking Autodesk to provide essential site design tools in Revit for a decade. Frustrated with Revit’s lack of basic landscape design features, Kaarsholm states, “the whole field of landscape architecture has been forgotten in BIM; there is no tool for them.” When I mentioned Vectorworks Landmark, he said he meant within the Autodesk ecosystem. 

“If you look at the Autodesk ecosystem, they say why not use Civil3D or Infraworks,” he says. But he could not believe the suggestion that he needed an infrastructure tool for his architects to simply do some grades and put in some grass alongside a building. More specifically, he noted that Revit could not create a cave for a parking garage and that when you cut a section in Revit, you end up with just cross-hatching. 

It is important to note another aspect of this story. After two or three meetings that included firm heavyweights like Grimshaw and Herzog & de Meuron, Kaarsholm successfully got the Autodesk Revit development team to at least prioritize a future set of capabilities that have existed for years, even more than half a decade in a rival BIM solution. The problem is that the industry lacks compatibility standards that increase the net benefit of all industry customers. Therefore, utilization of an alternative system for these particular needs is possible yet non-trivial. 

Why can a much smaller BIM rival have the features in their BIM solution Kaarsholm was seeking in Revit? How is it possible that smaller rivals out-point larger ones in technical capacities? Some will say smaller companies are more agile and nimble and faster moving. 

The more significant answer might be this: Companies are like all economic creatures and operate based on incentives. When your market share is large enough to create a vast third-party ecosystem and has extensive positive externalities, a considerable part of the expected present value of the system is placed in such externalities. In short, the core product’s value is not equivalent to the sum of its price tag but rather something less once you deduct the economic values gained by all the positive externalities that come with the core product. 

 

 

 

 

A smaller BIM competitor cannot offer the market equivalent economic value in positive externalities; therefore, it must compensate with either lower prices, better core features, or both. Thus, you can find the features Jens Kaasholm is seeking in Revit in rival BIM solutions, but equally, you cannot find the same benefit value in positive externalities. 

Autodesk Revit is not technically a monopoly; a significant industry concentration exists around it, but there is a critical difference. There are plenty of viable market options for BIM in AEC. Iain Godwin, former director at Foster + Partners, notes that the AJ100 firms in the UK typically have many Bentley Microstation licenses and licenses with other BIM systems. 

Quasi-Irreversibility of Investment

Still, despite the presence of alternatives, there has been an overwhelming sense by larger firms that standardizing on Autodesk Revit is the commercial decision that made the most sense. Why is it referred to as a “commercial decision” versus another type of decision? 

Dave Moyes, Information Manager Partner at SimpsonHaugh in Manchester, explains, “To be honest, the reason why we moved to Revit was commercially driven. It was not because it was the best product on the market. We still have a lot of Microstation seats here. We would be excluded from contracts if we could not deliver an RVT file.” 

Nick Dunn, ICT Director, PRP out of London, a large multi-office AE firm, adds: “Commercial for us means we needed to take this route to be more integrated with consultants.” Dunn spoke about Autodesk’s marketing machine and its ability to conflate Revit with BIM during the early BIM transition years. But marketing is not the only reason why engineers began to grab hold of Revit. Autodesk offered what is commonly called “closed BIM,”—meaning architects and engineers could work together within the same software system and file format. 

This is where the factor of economies of scale comes in—another pillar of QWERTY-Nomics. Working within the same system is what economist Paul A. David refers to it as “a decreasing cost condition.” In general, the more people join a particular technical system, the more the expected present value of that system rises in relation to falling costs for that system. One such considerable cost of any BIM or complex software system is that of training, an important aspect discussed below.

 

 

 

 

When BIG left Revit for Archicad more than six years ago and returned to Revit, Jens Kaarsholm explained that recruiting staff with experience with Archicad was an issue but far from the only issue. “The grass is not greener in Archicad, nor in Allplan, AECOsim, Microstation, Blender, Vectorworks, or any other BIM solution as it stands right now. But surely, recruitment makes it harder to switch to any of those.” When the firm was migrating contentiously back to Revit and had overlap, Kaarsholm noted that staff flexibility was an issue. “Staffing flexibility was challenging because skills across the two BIM solutions were unequal.” Another issue was that of maintaining two sets of templates and standards across two BIM solutions, reminiscent of the early days of telephones with banks replicating two or more sets of wires, junction boxes, outlets, and physical telephones. 

This set of issues is part of the “decreasing cost condition” of unifying on a dominant de facto standard system. But there is no doubt in this author’s mind that the most significant positive externality associated with such extensive standards is one of falling costs with respect to a large pool of trained people. But how does an industry avoid the various market failure conditions expressed in the Open Letters if a pernicious, self-reinforcing de facto standard fails to not just meet the needs of a small but influential segment of customers but more broadly demonstrates general development velocity concerns relative to its market competitors?

As economist Paul A. David noted in his paper, Clio and the Economics of QWERTY, “A particular system could triumph over rivals merely because the purchasers of the software (and/or the hardware) expected that it would do so.” David continues, “Although the initial lead acquired by QWERTY through its association with the Remington was quantitatively very slender when magnified by expectations, it may well have been quite significant to guarantee that the industry eventually would lock into a de facto QWERTY standard.”

This expectation factor appears to have a real cultural force in the AEC industry as well, and this force does play itself out not just between firms but also critically in academia. 

University and Cycles

This is where universities come into play. There is considerable debate about whether architecture schools should teach software systems or merely provide the resources for such learning. A more significant issue is that graduates need to be prepared for the industry, where universities inadvertently contribute to what architect Nick Dunn calls “the snowball effect.” 

Schools and instructors get in the business of encouraging students to learn the software systems that most firms (often their firms) use. Then the firms using alternative BIM systems struggle to find new staff with prior knowledge of competitive alternatives. This “snowballs”—to use architect Nick Dunn’s phrase—to switch to the software system that most people already know. The cycle is pernicious and self-reinforcing.

 

 

 

 

Moreover, the universities face a conflict of interest. One interest is serving the overall welfare of the industry for which they are training the next generation. That interest should focus on industry optimization and training the next generation with the skills to manifest that optimization. However, such training would likely cut against the grain of simply training for future employment. 

Universities may teach software but do not teach it how it should be taught. Iain Godwin, formerly a senior partner at Foster + Partners and Owner and MD of GodwinConsulting.Net, explains. “Graduates need real-world experience in technologies; they have very little experience or proficiency with technologies in a collaborative space like practice on the scale of projects people do as a norm.” They simply use the dominant tools used in practice on school projects working in isolation in most cases. 

They are also not taught how to think critically about technologies and base technology adoption decision-making on a critical applied economic framework. In general, architectural students are not instructed in business or economic skills, leaving them sheepish with respect to technology and practice culture. At the same time, they are simultaneously taught to think of themselves as visionary and forward-thinking in all matters related to design.  

next page: Superman Syndrome and IBM