One ringy-dingy, two ringy-dingy. The words surely call to mind – at least to those familiar with the 1960s/70s TV show Rowan and Martin’s Laugh-in – images of Lily Tomlin as telephone operator Ernestine. But the digital businesses of a very different era do not want to have to rely on manual machinations all too reminiscent of those that a switchboard operator of old would perform to bring parties together. No, to be a true digital business requires that connections be automated, not hardwired, says Dave Duggal, Founder and Managing Director, EnterpriseWeb LLC. Today, however, the world generally relies on manual integrations to make API-constructed composite applications and their interactions and transactions appear as if they are functioning in a seamlessly interoperable way, when in fact they are not. Dynamic APIs can change that.
EnterpriseWeb is promoting the idea of Dynamic APIs as a potential standard with bodies such as the Object Management Group (OMG) and the Industrial Internet Consortium (IIC). “You could never scale a global telecom network with switchboard operators,” Duggal says, and neither can the vision of a seamlessly connected world of digitized businesses be realized when the APIs that integrate services and systems are diverse to begin with, constantly changing, not normalized back to common sources and hard to manage. The result is that modifications to them often lead to breakdowns that arrive without notice, interrupting composite application processes and bursting the illusion of easy unity.
APIs can represent microservices and, in a world where everything is an endpoint, extract everything from databases, systems, machines, and devices for the Internet of Things. But how to efficiently and continuously coordinate that for applications built of these small units, each of which is a snowflake with a unique interface implementation: “If in my rich application, end-to-end we are connecting 30 things, every time one API changes, the whole app breaks,” he says.
“Model-driven API interoperability and evolution,” is how Duggal describes the Dynamic API concept that addresses the problem. “The idea is to move away from a discipline to a standard schema, a simple and lightweight way to communicate the model of the API.”
The approach avoids coding and endless integrations and re-integrations across endpoints. “Existing practices no longer support new demands. Manually coding and re-coding, and integrating and re-integrating simply doesn’t scale with Cloud and IoT,” he says.
The Dynamic API proposal promotes a Common Machine-Readable Pattern for describing heterogeneous endpoints as objects. The whole point of an object is to hide implementation details; but he says the trick is to not have statically defined objects (tightly coupled data and methods). “Our objects would be described as ‘deeply networked and highly-connected.’” They are, he says, graphs with conditional relationships – abstract data types, which mean that they must be interpreted for context. Specifically, the idea proposes normalizing all references to or having shared references to the API’s data model using links, policies, and human- and machine-readable Metadata. “Automate those, so Metadata is searchable, links are navigable and policies are executable,” he says. Accepting the fact of API change and agreeing on how to handle change in advance, instead of being tied to static schemas and implementations and tight coupling means that, at a minimum, when a publisher changes the interface to update, upgrade or replace a service, a consumer receives a realtime notification.
“If I have consistent semantics for making changes, I can anticipate change. So I can say when my app sees change, send out a message to the IT office or have systems negotiate the change on the fly,” he says.
Spread the Concept
EnterpriseWeb wants to be a good citizen by promoting the concept of Dynamic APIs, independent of its platform, as it believes it’s critical given the top-down demand for enterprises to become data-driven, agile, digital businesses. The ideas behind it are good for business, even if companies don’t employ them with the help of the EnterpriseWeb platform for which the concept of Dynamic APIs as described is a core construct. “We’ve made many IP contributions already to help advance the industry,” he says. “We understand to grow a market you need to share, and that’s what we are doing.”
Dynamic APIs, he says, support a more interactive way of working with software in general, as it means that APIs are actually bound at run-time. This means higher level application logic and algorithms can automate decisions about selecting which partner or internal API to use based on context. “EnterpriseWeb itself runs completely on these principles. Every interaction is a real-time transaction. The system uses interaction Metadata to interpret conditions, translate policies, make decisions and execute all necessary operations,” he says.
While companies don’t need EnterpriseWeb to use Dynamic APIs, he says, the more value businesses see in the concept, “the better for them and for us.” And that shift is coming, as traditional middleware use cases decline and expectations grow for APIs to function smoothly and consistently as integration solutions. “Big IT can’t defend the status quo much longer,” he says. “We talk to a lot of these folks and they are looking at the problem very closely themselves. If you sell $10 billion of middleware, of course you’d like to continue to sell that, but this is what disruption means.”
As Duggal explains it, consider the example of a major organization acquiring another big company and wanting to move one of its divisions to an existing internal division. It could wind up taking a year and costing millions of dollars as IT tries to sort through enterprise architectures rife with complex composite applications built of discrete APIs and services joined together in rigid and hierarchical ways, and then join them to similarly complex composite application architectures built of discrete APIs and services joined together in rigid and hierarchical ways.
EnterpriseWeb and its Dynamic API technology could speed that up considerably with its automated and model-driven APIs, so that intelligent agents can weave connections across endpoints in realtime. “We represent all endpoints as objects, which hides all its complexity, whether it’s a database or a device,” he says. The business doesn’t care about the syntactical differences between databases, for instance; it just wants to connect what it has, fast.
With the platform, users can graph objects and relationships, including associated dependencies and constraints. Now, with a common design pattern so that objects all look the same, it’s possible to search and navigate through them in the same way, and to compose objects by just pointing and clicking using Metadata and graph relationships. “You can do lifecycle management over the top from one common layer without having to manually integrate them all,” he says. If anything changes, since nothing is tightly coupled, you can just update the objects and the connections won’t break, he says.
“You can represent and connect things more naturally working with objects that you haven’t been able to do before,” he says. In the case of the enterprise’s acquisition, for example, one object could represent the division to be moved; it could simply be remapped to another division, with all its history preserved and new rules from the division it’s been added onto applied with a simple drag-and-drop operation. The EnterpriseWeb platform, Duggal says, provides a one-stop-shop for modeling an org hierarchy (sets of unit), ontologies (sets of concepts), data (sets of entities), processes (sets of tasks), networks (sets of nodes), and so on.
“Everything is declaratively composed from sets of conditional relationships. This makes personalization, change and extension very easy,” Duggal notes. “This common approach is the antidote to diversity. Things will always be diverse, but it helps to have a high-level abstraction that makes these objects looks the same so I have visibility (search/navigate), composition, and central policy control and lifecycle management.”
Bring on the 21st Century
“You have to rethink things for the 21st century,” he says, and this century requires being able to get above individual technologies to connect things in a more natural way. “Our thesis is that in this century the greatest value is interoperating across everything for integrated operations and dynamically connected value chains.”
EnterpriseWeb as an application fabric platform also gives the enterprise an architecture that it can scale, building into it properties of asynchronicity, parallelism, distributabilty, immutability, security, and resiliency. This, he says is critical. Currently, when companies build apps, they do it on a one-off basis and rely on practices and discipline, he explains, but the reality is that with each new app everything is coded quite uniquely. There is little or no re-use or consistency. Also, such work requires developers to still struggle to make apps distributable, parallel, asynchronous, resilient, secure, and so on.
Says Duggal, “EnterpriseWeb addresses these non-functional concerns as affordances of architecture so they are centrally controlled and consistently enforced. We can do this because we late bind everything. Applications can have conditional relationships to security/identity, business compliance, IT governance, and system control policies – voila, re-use and consistency.”
EnterpriseWeb goes to market through its partners, such as system integrators. Most of its customers come to those parties with a specific problem to solve, such as using its fabric to create model-driven connections in order to onboard existing systems, whether it involves Java Database Connectivity, RESTful APIs, web services, or microprocesses. “The system literally does algorithm matching to find entities inside the schema that map to concepts that exist in EnterpriseWeb,” he says. “So it makes recommendations on mapping to system concepts, essentially bootstrapping the migration process and making it possible to build out a first application very fast.”
At the same time, as an architecture the platform lets users think bigger, acting small first but scaling on success where other options have failed, he says. Rather than replacing enterprise systems or existing algorithms, “we just want to be the fabric to connect things in loosely coupled fashions and compose them into dynamic applications over the top,” he says. “That’s the value proposition – end to end interoperability” – the power of using a platform based on a thoughtful architecture built from the ground up for highly-modular systems and distributed processes. When a company isn’t building static silos, but instead simply adding to system libraries keeping everything horizontal, it can evolve, extend, and iterate as it sees fit. “This doesn’t mean we are providing all the value. To the contrary, our primary role is being a flexible/extensible fabric for connecting IT assets (systems, databases, algorithms, services, APIs, etc.) for dynamically integrated business operations,” he says.
Most recently, the company participated in the 2016 Catalyst Awards with Infosim, which received the Best New Catalyst for its smart industrial manufacturing concept, and The Welding Institute. It used its Dynamic API schema to extend standard APIs to connect and coordinate dynamic end-to-end processes to facilitate controlling robots on a factory floor. Orders sent through the cloud could be controlled dynamically, monitored and changed in a distributed way to dynamically fulfill orders.
The project and the recognition is a big deal, Duggal says:
“We showed how one platform could support advanced virtualization, sophisticated industrial internet, automated data and system integration pipelines, and dynamic human processes. This is of course what anyone would want, a unified tool chain. Everyone has just been used to being ‘sold’ different middleware and tooling for everything, so they keep digging their hole deeper and deeper. Our innovation is throwing out the old playbook and re-thinking the middle-tier for the needs of the 21st century.”