Before I start, I want to thank Viktar Beliakou, a former coworker and now CEO of Enji.io an emerging startup in engineering and scientific calculations, for enthusiastically agreeing to collaborate on this short piece. It is always a pleasure to share thoughts with you!
APIs, or Application Programming Interfaces, are emerging as a significant force in architecture, engineering, and construction (AEC). In essence, an API allows one application to request data or trigger functionality within another application in a streamlined, consistent manner. APIs enable a world of possibilities by allowing software to share data, execute functions, and access resources. This modular approach makes development easier, allowing teams to add new features without starting from scratch.
For large AEC organisations, APIs have the potential to not only streamline operations but also activate the “long tail” of niche solutions developed internally. In simple terms, the “long tail” concept refers to a strategy that taps into the power of vast numbers of specialised, low-demand solutions, which individually may serve specific purposes but collectively represent substantial value. This concept has huge potential in AEC because many tools and scripts are developed to tackle unique project challenges. With solutions available via APIs, people can easily consume them into their projects instead of starting from scratch and recreating everything. This can really drive improvements and innovation among different teams and projects.
In AEC’s vast and varied landscape, you often find specialised tools and solutions that pop up to tackle specific needs on different projects. Take the transportation sector, for instance; they might use structural data analysis tools, while water management teams have to deal with fluid calculations. Regarding computational design, the “long tail” idea fits well with the variety of tools and scripts created for projects/processes that tend to be “similar but different”. A one-size-fits-all solution is rarely effective, so teams need the flexibility to quickly assemble solutions that draw on existing tools while adapting them to the unique demands of each project. This diversity allows designers and engineers to address various challenges with agility, efficiency, and innovation. However, unless these tools are interconnected, their impact remains limited, confined to isolated teams or projects rather than making a bigger positive impact on the whole organisation.
While each API may offer value, strategic evaluation is essential in deciding which tools should be exposed as APIs. Instead of creating every possible tool, organisations can strategically concentrate on those that realistically have the potential for reuse in future projects. Instead of creating every possible tool, organisations can strategically focus on those that realistically have the potential for reuse in future projects. By adopting an API-centric approach, AEC enterprises can implement a scalable method for delivering specialised functionality throughout the organisation. This strategy enables different teams to utilise established solutions instead of duplicating efforts. The advantage of this approach is that it reduces redundancy and ensures that valuable insights captured in these tools are shared and maintained across projects.
The Coca-Cola example
We don’t debate the need for APIs. We just do it.
Because we need to look to other industries for good models, Coca-Cola’s digital transformation journey is a great example of the benefits of this API-first approach.
Coca-Cola redefined its digital ecosystem by focusing on two dimensions for each solution: immediate value and future potential. Every digital initiative was designed not only to solve a current business problem but also to create reusable “puzzle pieces” that could serve as building blocks for future innovation. As Coca-Cola began delivering these API-enabled components, they gained the confidence to experiment with new technologies and applications, mapping out core domains of their business for broader digital transformation.
For AEC companies, following this model means turning specialised tools for structural analysis, environmental modelling, project scheduling and more into easy-to-use API assets that everyone can access. Like Coca-Cola, AEC firms can use these modular components to spark innovation by mixing and matching tools and services in surprising ways, letting teams try out new applications. By making these niche solutions available and customisable, an API-first approach helps AEC companies discover new ways to boost efficiency, collaborate better, and explore digital experiments across various projects and departments.
Building an API ecosystem
Creating and managing APIs within large enterprises requires a thoughtful approach. It’s not just about giving access to code or data; it’s about curating the available APIs and creating an API ecosystem that fits the company’s goals. Establishing an internal API marketplace lets team members discover, rate, and even contribute to APIs on this platform. This catalogue will grow as a library of resources, encouraging cross-project and cross-discipline collaboration by allowing even the most specialised tools to find their audience within the organisation, building a community that can share feedback and suggest improvements.
However, an API’s lifecycle does not end with its creation. To keep them valuable, APIs need regular updates, good documentation, and active support to meet changing needs and standards. Having clear and user-friendly documentation is key because it turns APIs from standalone assets into essential resources for everyone in the company.
The impact of APIs
The business impact of embracing an API-first approach in AEC enterprises goes beyond merely sharing tools; it’s about creating an ecosystem of interoperability that streamlines operations, improves data integrity, and fosters collaboration across project teams. For example, by standardising calculations and making it easy to check regulatory compliance, companies can ensure consistent data and processes in all their projects. This easier access leads to better decision-making and helps cut down on mistakes and reworking by ensuring everyone is using the latest and most reliable tools. By unbundling core business capabilities into API-enabled digital services, companies can achieve the goal of a connected enterprise where tools, data, and insights flow seamlessly across project boundaries.
APIs as a catalyst
APIs can be a powerful tool for extending collaboration and opening up new possibilities for services and business models. Jeff Bezos’s mandate at Amazon was clear: “All teams will henceforth expose their data and functionality through service interfaces.” This directive aimed to infuse a culture of collaboration, ensuring that every service could be reused and potentially externalised.
The API-first approach flared a culture of innovation within Amazon. Teams were encouraged not to rely on direct integration but to build interfaces that others could use internally and externally. This fostered agility, allowing Amazon to adapt to changing markets and customer demands quickly. What began as a way to improve internal efficiency evolved into a foundation for external services like AWS, illustrating how APIs can transform from internal tools to industry-wide services.
The AEC industry is slowly starting to follow a similar path, driven by forward-thinking startups and industry pioneers who are beginning to distribute APIs openly to foster collaboration and shared innovation.
Chatting with Viktar, explained that making the API accessible is a fundamental part of their platform—a move some might view as risky—it’s a deliberate step to build a community-driven approach to feature development.
“Our core intellectual property isn’t just in the algorithms,” he shared. “The API we open isn’t about exposing our core product; it’s about making the underlying schema accessible to encourage collaboration and feedback. This way, we can prioritise enhancements that meet real market needs.”
Viktar sees this approach as a model for other enterprises: by maintaining proprietary control over essential software while selectively open-sourcing non-core elements, such as data schemas, companies can foster innovation and improve interoperability between teams, vendors, and stakeholders without sacrificing competitive advantage.
We’re not risking our key advantage by open-sourcing our formula definition schema. In the future, our established reputation and accumulated business insights will still differentiate us even if competitors attempt to replicate parts of our platform. In B2B, switching to a new system is complex and costly, so companies are unlikely to do that, even if a cheaper option exists.
Conclusion
APIs enable modularity and adaptability, allowing companies to respond quickly to shifting project requirements and emerging opportunities. This flexibility, however, is possible based on close collaboration between product, digital, and IT teams.
Such alignment between business goals and technical solutions fuels continuous innovation, transforming it into a core strength of the business. This approach allows enterprises to dynamically adjust digital services to meet client needs and create value throughout the project lifecycle. An API-first strategy requires vision and long-term commitment; instead of focusing on disrupting existing processes, leaders should think about enabling creative reuse and improving existing processes; by strategically selecting and connecting the “long tail” APIs, many valuable solutions can be discovered, developed and scaled, supporting teams, processes and projects. As these APIs develop, they can also bring value to outside partners, opening up chances for new collaborations or services. Companies embracing this flexible approach are better positioned to navigate industry changes and uncertainties.
A huge thank you to Ben for his invaluable support.