Synergy and Alignment — The APIs Democratizing Role

AT THE INTRODUCTION OF THIS SERIES, I stated that the Revit Open Letter story wasn’t fundamentally about Revit. Of course, and naturally, the letter itself and the group behind it singularly target and see it about Revit. But I prefer to take a bird’s eye view of the AEC industry as an industrial sector coping with its own transition from the paradigm of the “mass-production” revolution to and through the “ICT revolution. (ICT = information and communication technologies)

These terms, “mass-production” and “ICT revolution” refer to economic historian and theorist, Carlota Perez’s phenomenally influential work in the field of “business cycles” and technology revolutions and their linkages. Her techno-economic paradigm (TEP) model has had a profound impact since the publication of her first book, “Technological Revolutions and Financial Capital,” published in 2002. Here is what Irving Wladasky-Berger, Chairman Emeritus, IBM Academy of Technology said about her work:

“Carlota Perez has influenced and educated a whole generation, me included, on how to think properly about technological revolutions, as well as on the dynamics linking such revolutions with the seemingly unrelated gyrations of the financial industry.” 

While her TEP model helps one who writes about digital technologies think “properly” Perez herself warns about the dangers of interpreting current reality based on “recurrence” (her hypotheses in her model have been tested against the historical record). Still, I feel a mode of confidence wrapping up this series while attempting to frame (re-lens) AEC digital developments based on her model. It certainly helps when Perez herself writes in the comments section, “A pleasure to see my theory well understood (here and in other blogs by Anthony Frausto-Robledo) as a macro-context to the way specific technologies evolve.” 

Perez’s TEP Model

Since a proper explanation of Perez’s Techno-Economic Paradigm (TEP) model is beyond the scope of this article, I refer the reader to several articles on this site that place it as a macro-context for AEC innovation. (here) and (here) and (here).

But in a nutshell, the ICT (information and communication technologies) revolution began in the early ’70s with the key invention of the Intel processor. The Perez TEP model says that successive technology surges in human history since the first Industrial Revolution pass through two distinct periods (large phases) with two sub-phases each. The first period is called Installation, the time when the new revolutionary innovation gets “installed” into industry and society, uprooting the old paradigm and creating great opportunities for the investment and capitalist class and great disruption for everyone. There is a Turning Point (a kind of overlapping period) between Installation and the next major period, Deployment. By the time we reach the Deployment period (generally it takes 20-30 years from the revolutionary invention’s birth) the old “technology regime” (or common-sense way of doing things) has been upended and replaced. 

 

 

 

 

For instance, from the birth of the Intel processor in 1971, AEC professionals had essentially fully digitized from hand-drawn blueprint drawings to computer-aided design (CAD) drawings by 2000 (the year of the Dot-Com Bubble crash) as the common-sense new way of working. In essence, the new digital tools of the new ICT paradigm had been installed. 

At that point, a Turning Point, with its attendant financial crash and inevitable reset should have commenced. It sort of did, but it was a preview of the real financial turning point that emerged with the Great Recession nearly a decade later. In the meantime, the ICT revolution continued to give birth to significant successive waves of innovation (eg: higher speed cellular networks, mobile devices (first iPod then iPhone), and the big one, the cloud-computing era. These items constitute in Perez’s terms a “cluster of innovations” that are interdependent. And they have all had an impact on the AEC and manufacturing industries. 

Why the API

In that cluster of innovations, cloud computing technologies gave us software as a service (SaaS) through our web browser. Andrew Anagnost told me on our call he sees the future of Autodesk software as embracing the SaaS model, but with a twist. He believes the computing industry will follow the “app model” that sprung forth from mobile devices and that “thick clients” (and Autodesk Fusion is one) will play a larger role in Autodesk’s future AEC solutions. Either way, via browsers or through thick clients, APIs (application programming interfaces) that are published and open for others to code into, will enable apps to talk to each other, passing various types of data from the powerful servers in the cloud back down to the client app (browser, thick client on your PC, or mobile app on your iPhone). 

The death of the “file” is not going to be a quick death and it may not happen in any of our lifetimes. But when it comes to AEC, Anagnost sees the file as a “dead thing still working.” And he is hardly the only one. In our last Xpresso newsletter, we wrote about the AEC Delta Mobility project, a collective of AEC industry players consisting of engineering giant, Buro Happold, UCL, Rhomberg Sersa (Rail Group), and 3D Repo, with additional partners from HOK, Georgia Tech, ARUP, Hypar.io, SNC Lavalin, and Atkins. 

Anagnost and Autodesk aren’t ready to release the details of their future APIs that will open up and improve interoperability (democratize) allowing data flow between not just Autodesk applications but importantly among non-Autodesk applications. The Revit Open Letter group pointedly asked for better interop from Autodesk, principally through IFC (a file format) and better interop (ie: interoperability) with geometry from other solutions in and out of Revit. What the open letter didn’t ask for was the use of APIs for better interoperability. But that is where Anagnost, a veteran of the manufacturing CAD industry, believes the future of truly robust interoperability lies. 

“It’s funny that you sent me the link on the people working on the AEC Delta Mobility project,” says Anagnost. “That’s the kind of stuff we are working on behind the scenes with Forge, this notion of both data APIs and data workflows.” It should be cautioned now that there is a big difference between Forge and the work being done for the AEC Delta Mobility project. That project has three project deliverables, including an Open Delta specification, an open REST API specification, and open-source reference implementations. 

As written in Xpresso, the AEC Delta Mobility project is specifically addressing the problem of how we share information in the AEC BIM industry. Today we share entire models (again these are “files” being transmitted over the Internet) but in the future, we will share only the data that has changed in the models (deltas). 

The current method is just as inefficient as in the world of changing 2D drawing files, to some extend. Both methods create large payloads, create problems for tracking changes, and are inefficient. AEC Delta project technology wants to be “transactional” not on a “file basis” but on a “diff” (diffing) basis. The term “diffing” comes from the GitHub world and it relates to how modern software is developed across geography and time. 

Dr. Al Fisher of Buro Happold leads a talk about this project which you can find a link to here. (go to the Curated content section: The future of BIM Interop 

What the AEC Delta Mobility project is doing is democratizing BIM workflows and the way data is handled in AEC. It is fundamentally aligned with synergistically connected to larger trends in the cloud computing era we live in today. And we can see this playing out more prominently in major AEC tools that exist that emerged as cloud+mobile development. 

For example, visit Procore, the first unicorn SaaS tool in AEC history and favorite SaaS platform for contractors and owners in US-based construction. Procore can be integrated with not just other AEC industry tools (like Bluebeam or Egnyte) but also with general business cloud tools like Asana. 

So an architect could conceivably set up a bespoke digital workflow that passes any new RFI (request for information) from a general contractor using Procore to appear in her firm’s Asana application where the architecture firm handles projects and tasks management. Then that same architect can be notified while at lunch while gazing at her iPhone because it runs the Slack app and because she set up Slack to Asana integration so that any new task assigned to a particular project sends a notification into Slack. 

What does this integration-based custom workflow solve? 

It solves many things. It means the data about the RFI moves into Asana where the architect centralizes her daily task management. No more checking in on Procore often to keep up with contractor demands. It means control, whereby the specifics of which Asana projects have the right to interrupt the user. It means better time-management whereby the Slack notification that carried all the way from Procore can be snoozed as a reminder in 60 minutes so that coming back from lunch where a co-worker interaction could distract you, a digital workflow has your back. And it means flexibility—the power to one day use different, better, or less costly tools to replace any of these three in another bespoke digital workflow. 

Now that’s democratizing and empowering. And that’s just one example. Longer integrations are possible. Colleagues could have similar integrations but with unique parts (apps) in their integrations. Cloud tools may vary. It is possible to imagine bespoke workflows where colleagues and teammates use a variety of different workflows customized to their exact needs. One can image Slack for example advancing its snooze features so they automatically happen during certain hours of the day. Notifications at lunchtime on Wednesdays when you lunch regularly with your father and need a clean breakaway from work? Sure, one could program that. You won’t get the RFI notification between 12 – 1 pm on those days, just all the other days of the workweek.

The possibilities for API integrations are unfathomably limitless. And with AI systems just around the corner, AI integrations will learn what settings work best for us, and make suggestions for tweaking settings so our workflows continue to optimize our personal daily lives.

Let’s return back to Perez’s TEP model and look at how APIs are fundamentally responding to stalling improvements with the key factors of the paradigm itself.

Synergy and Alignment

“Synergy” is the name given to the first phase in the Deployment period, after or overlapping the Turning Point, in the TEP model. Perez notes in her book, that the Synergy phase is about supporting the expansion of the paradigm across the productive structure. It would be useful now to note some differences between the “tenets” of the ICT era paradigm versus the mass-production era paradigm it is replacing. 

The Old vs New Paradigm

Key to this discussion, tenets of the prior paradigm (mass production) include “standardization,” “dedicated equipment,” and “centralization,” as compared to the ICT’s tenets of “customization” (bespoke), “flexible production systems” (interoperability), and “distributed intelligence” (segment expertise). 

Another critical tenet of the ICT paradigm is “rapid changes in product mix,” versus the old paradigm’s “rather stable product mix.” The former flies in the face of “sequential designs and production” but is necessary for the “concurrent engineering” of the ICT revolution. This transformation has already begun affecting the models governing software development. The connecting APIs emerged from necessity. 

The File as Bottleneck

“At first, these innovations may appear (and in fact may be pursued) as a means to overcoming the specific bottlenecks of the old technologies, but the new key factors and related sectors soon acquire their own dynamics and successive innovations take place through an intensive interactive process, spurred by the limits to growth that are increasingly apparent under the old paradigm,” writes Christopher Freeman in the book, “Techno-Economic Paradigms: Essays in Honour of Carlota Perez.”

I would argue that the “file” as conceived in the era of desktop computing, a metaphor reference inside a set of metaphor references (eg: desktop, trash, folders, etc), is a carry-over from the era of mass production to ICT, a sort of bridge term like the term “horse-power” assigned to modern engines. Perez notes that often the technologies that start a new techno-economic revolution may not look familiar to the technologies that finish it in its “maturity” phase. Successive technological innovations enable the essential features of the ICT revolution to further advance, diffuse, and establish markets. The power and importance of the “file” wanes; the API and the relational database structures of modern cloud computing will ascend the file’s limitations. 

Key Factors

The key factors of a given paradigm are sometimes called “core inputs” in Perez’s TEP model. The primary key factor of the ICT revolution is the computer chip (as invented by Intel) in “operations per cost” (operations per thousand US dollars, for example). A second key factor is “data transmission size per second” (over the Internet). All key factors of a techno-economic paradigm must fulfill three conditions, writes Freeman: 

(1) Clearly perceived low and rapidly falling relative cost.

(2) Apparently, almost unlimited availability of supply over long periods

(3) Clear potential for the use or incorporation of the key factor or factors in many products. 

Speaking to the first of those above, Freeman notes that Rosenberg (1976) and other economists have shown that small changes in the relative input cost structure have very little effect on the behaviors of engineers, designers, and researchers. He writes, “only major and persistent changes have the power to transform the decision rules and ‘common sense’ procedures for engineers and managers.” This means that innovations that seem to speak to new modes of procedural structure in industrial processes but don’t generate rapidly falling relative costs will not yield take-up and re-organization. 

 

 

 

 

With Moore’s Law stalling, the AEC industry, along with other industries, have been in search of new key factors that meet the three requirements above. The second critical key factor of the ICT revolution, the speed at which we can send data over the Internet, isn’t leaping through leaps and bound either. Though 5G promises much. It is understood now, given the maturity of the earliest key innovations in the ICT revolution, that the API and modern web technologies (like the REST API) can spur on new developments that promise productivity gains that can lead to lower costs for generating outputs. 

Flexible Production System

With the greater awareness of the economic value of data, its transmission speed becomes ever more critical. To find “clearly perceived low and rapidly falling relative costs” on this key factor, the AEC industry’s leading providers must innovate at multiple levels. The use of “delta” type technology, and APIs to transmit not complete models each time, but time-sliced changes to the model seem very fruitful. 

At the same time, as we approach the Synergy phase of the Deployment period of ICT, tenets of this paradigm like “flexible production,” “concurrent engineering,” and “rapid changes in product mix” all conspire against one-size-fits-all large monolithic applications. That Andrew Anagnost explains the future of Revit in hybrid terminology (“thick clients” surrounding it, complementing it, overlapping, and eventually making it obsolete) suggests that Autodesk is at least mentally at the forefront of the next wave of innovations in ICT. The challenge for them is to recast their thinking about how to engage the cloud and APIs so that they provide their own customers with true democratized choices for data API connections. That they seek not to set the de facto way of doing things—an ode to the virtues of the old mass-production tenets—but do things that embrace, sponsor, and reflect the virtues of truly flexible production systems. 

Closing Thoughts

A couple of final thoughts. The Revit Open Letter didn’t ask for flexible production systems via APIs because this type of technology, like the AEC Delta Mobility project, is “early stage.” Flexible production systems are another way of expressing the democratization of tools, data, and digital workflows. But this is what they mean by their requests for true data interoperability and adherence to agreed-upon industry standards.

That agreement is a part of Perez’s TEP model and the essences of the “Synergy” phase through “conformity to institutional alignment,” However, the API directions in AEC are falling in-line with synergistic directions in the umbrella Techno-Economic Paradigm (TEP) itself. In other words: APIs are eating the world and the AEC industry needs to synergize with this trend. 

The last thought. Much has been said about the Revit Open Letter. One thing not yet said is this: shouldn’t all major pieces of a flexible production system have pricing pressure applied to them? How can an industry (AEC) known for tendering and competitive bidding processes profess a frustration with the price of a key component of a desired flexible production system (Revit) when they have not subjected it to the same pricing pressure inherent in the AEC system itself? Am I to believe, as an architect of three decades, that the AEC industry wishes to hand over the digital backbone for our industry to just one vendor (winner-take-all, till the next open letter)? 

It’s time for the AEC industry to realize, that from the architects, engineers, contractors, subs, suppliers—and the “suppliers of the digital tools”—that the same competitive pressures need to apply to all of us—a literal metaphor of the world of API integrations itself.  And that the development of a flexible production system for AEC must make that painless and in the words of Perez—”common sense.”